Making Design to Manufacturing Easier, Faster, Better
Full transcript below:
Murray Slovick:
If you need assistance solving common issues, please click on the yellow help icon below the slides. Additionally, we welcome your questions during today’s event. We will answer as many questions as possible during the Q&A session that will follow the main presentation. Please feel free to send in your questions at any time. To do so, simply type your questions into the question window on the side of your screen and hit the submit button.
Also, please be aware that today’s session is being recorded and will be available on the Electronic Design website within the next week. You will be notified by email when the archive is available. You may also download a PDF copy of the slides by clicking the green folder icon in the toolbar beneath the slides. Now, let’s meet today’s speakers. Bill Orner is the Director of Advanced Hardware for GoPro and he manages the hardware development team which supports multiple product teams in three countries.
In addition to design, the advanced team also investigates and develops new design methods to improve time to market and reduce design complexity. Bill’s 30 years in the consumer electronics industry includes working for Philips, Transmeta, MIPS, Lexicon, as well as several startup companies. During his career, Bill has led the design of more than 50 production products. In addition to managing design teams, Bill has also managed the implementation of multiple PLM systems, as well as design tool integrations to PLM. GoPro helps people capture and share their lives’ most meaningful experiences with wearable and gear-mounted cameras and accessories.
Michelle Lee is the PLM Product Manager at Nimble Storage and has over 30 years of experience in Silicon Valley at startups and international companies in the fields of telecommunications, consumer electronics, and storage. Michelle has implemented business best practices for product design and production in conjunction with ERP systems such as ASK MANMAN, Expandable, Oracle, and Fourth Shift.
She has been involved in the PLM integrations with multiple ERP systems and has experience in quality processes using PLM eight-step corrective action, deviations, and stop ships. Nimble Storage is a leader in predictive flash storage solutions, and they provide flash arrays, adaptive flash arrays, and timeless storage.
Scott Reedy is the Director of Product Marketing at Arena. He has held consulting, sales, and marketing positions in the PLM industry over the past 18 years and was instrumental in helping large SAS solutions at his last two companies.
Prior to working in PLM, Scott spent a decade managing engineering services for a global manufacturing company. Arena has been providing cloud product development solutions since 2000 to help companies to design, produce, and deliver innovative products to market. Now, I’ll turn things over to Scott Reedy to kick off the discussion. Scott.
Scott Reedy:
Great. Thanks, Murray. Today we’re going to be exploring how product teams can benefit from greater control and accountability using product development systems like Arena PLM to make design to manufacturing easier, faster, and better. Let’s start by considering how product team dynamics have changed in recent years. We’ve seen that product development has become more complex with global product teams that include distributed design and manufacturing partners that might be component suppliers and contract manufacturers.
We’ve seen that with these distributed teams, shorter release cycles, and increased environmental compliance requirements, the need for better control and collaboration has increased. What is the impact? Well, the impact of having these distributed product teams might include the inability to find the right information or the right data at the right time, lost intellectual property, maybe slower release cycles, sourcing quality and design issues, and even building to the wrong revision, which results in scrap and rework. All of this ultimately leads to higher costs, reduced profits, and lost market share.
I’d like to start our panel discussion with Bill. Bill, what changes have you seen with regards to how product teams need to work today versus maybe five or even 10 years ago.
Bill Orner:
Well, we can’t rely on tribal knowledge anymore. Staff turnover and multi-project environments are a challenge. If it’s not captured, it’s forgotten. Some critical engineering roles have also become luxury items. Competition and better systems have reduced some dedicated roles, like component engineering and some aspects of document control. For example, part creation BOM input, daytime change control boards now happen at night. These activities are still necessary and are important to prevent the creation of duplicate parts. Some activities can be crowdsourced with good systems and connected teams in a controlled environment.
Scott Reedy:
Great. You talked a little bit about one area, preventing creation of duplicate parts. How is that done today? How do you go about that activity?
Bill Orner:
The most important tool to prevent the creation of duplicate parts is having good search in your PLM system. Before you create a part, which is a lot of work, you want to see if it exists already. If you have descriptions that are intelligently put together and easily searchable, have thumbnail pictures, it makes the whole process of finding existing parts really fast.
Scott Reedy:
I think just a comment on one of the points that you made, when we look at how times have changed and how functions have changed, if you look at document control, we’ve just seen these functions evolve over time. In the past they might have spent a lot of time doing some basic task, like checking out part numbers, entering bill of material data, maybe chasing ECO approvals. Now we really find that these teams can focus on more strategic activities like analyzing new product introduction or change processes to make sure that those processes are optimized.
Michelle, you spend a lot of your time on the production side of the product process, which includes coordination with supply chain partners like contract manufacturers, service depots, and design partners. How have you seen supply chain relationships change in recent years?
Michelle Lee:
In recent years, the online 24-hour demand is real critical for all supply chains, or your manufacturers, et cetera. Because you might be having two manufacturing sites that require to have access to real-time data. With this real-time data, they’re able to build and ensure they have the right information and implementation requirements for building the product. The other thing that happens, too, is with our supply chain partners, sometimes we have turnovers in our project managers.
To keep that data integrity within Arena, we’re able to communicate that to the new project manager. Very simply, by going in and I have a training session with them to show them all the critical data they need to manufacture the product that we have on our orders.
Also, when we share that information, we give them access to the working and effective, so they have the red line accessibility, so they can actually see the changes, so they can implement it into their PLM. The other commitment to the education, I do that quite a bit in a yearly basis, because we do implement new functionalities within Arena on a yearly basis.
Currently I’m implementing change requests which will be also trained to our CMs. This way they have tribal, not just the knowledge, but they can usually access it and give comments, and collaborate all the information. Some teams don’t have access, and we control that through the security of the supply chain. We also have some of our critical component manufacturers also in Arena, so they have access to make sure that they see the bigger picture of changes that are coming, deviations that are coming, and any other kinds of impact to the product building of the storage arrays.
The other thing, too, is if we have quality issues, we do have the CAR process. We’re able to also communicate and resolve issues in our CAR process with our manufacturers also.
Scott Reedy:
Great. Thanks. I liked one of the things you touched on, because in my background working in engineering services and in manufacturing companies, you need to make sure that people know how to use the system. It’s only as good as it can be if people actually know how to use it and they’re willing to use it. I like the fact that you’re revisiting training with your partners so that they’re always aware as to what it is that they need to be doing.
Thinking about product teams and the distributed nature of those teams, we recently analyzed our entire customer base to understand how their product teams are accessing Arena around the world. We found that about 52% of our customers access Arena internationally, and 56% of their suppliers access Arena outside the U.S. As a result, we believe that product development solutions must easily support the appropriate type of collaboration anytime and anywhere. That means having formal collaboration with secure supplier access, so that they can access your product record and your intellectual property.
Also, having informal collaboration with real-time discussions linked directly to the product, not distributed email threads, or it’s not connected to the product. Then, finally, being able to share the latest controlled revision of your product, or what we might refer to as the bill package, so that your suppliers can bid and execute on their manufacturing partners, on their manufacturing purposes I should say.
We’d like to get the audience feedback today on a few polls. I’d like to start with this poll. If you could take a minute, I’ll read through it, and then if you can answer that would be great. We’ll publish the results. How distributed are your internal and partner product teams? Do you have one site and no partners, one site and a few partners, one site and many partners, multiple sites with no partners, multiple sites with a few partners, or multiple sites with many partners?
I’ll let you go ahead and lock in your vote. We will publish this in just a minute. We’re still gathering a few more results. Looks like we’re creeping up. (SILENCE.) We’ll give it about another 10 seconds. (SILENCE.) What we see is that about 15% have a single site with no partners. We’ve got a few that have a single site with a few partners, maybe 23%. It looks like there’s a lot more that have multiple sites and at least a few partners, so between a few partners and many different partners.
This aligns with what we see today with complex products, so maybe 50% or more of you are dealing with a variety of different partners, whether it’s on the design side, or the contract manufacturing side. Bill, I don’t know if you have any thoughts about that. Are you surprised by those results?
Bill Orner:
Not at all. The nature of the way the world is operating with external companies who do specialized functions that you want to take advantage of in your product offerings, or design processes.
Scott Reedy:
I agree. Let’s move on. Now, I’d like to ask Bill the following. I’d like to talk a little bit more about structure and control. You mentioned earlier why relying on tribal knowledge should be avoided. PLM systems create better control, so how does this affect your product design processes?
Bill Orner:
We strive to get everyone involved in the process and the systems. Sadly, the half-life of many engineering teams is about two to three years. Tribal knowledge is nonexistent. If PLM works well, it makes everyone’s life easier. It’s not a burden. Having some structure and control doesn’t mean that it’s restrictive. Control is not mutually exclusive of innovation. I can’t say this enough. I keep giving this speech at many companies. When it works well, it makes your life easier.
There’s a level of control required to avoid development problems—for example, wasted efforts, duplicate part creation, designing and building to the wrong revision, and I’m sure many people on the phone have experience personally having something fabricated off the wrong revision. It’s very embarrassing when you have to explain to your boss. I don’t want to go into detail on that.
Having good systems in place doesn’t slow business down. It actually helps to accelerate the process. I’ll give one quick example. They had a CM at my last job. Called them up to make 10 rush prototypes. We told them to use the latest BOM that’s in Arena. I gave him a PO number on the phone, and it’s done. Finished.
Scott Reedy:
That’s great. That’s great. I know in our experience we find that design teams are generally more receptive to leveraging PLM systems as long as it allows them to do the majority of their daily work, or their day-to-day activity in the CAD design system of choice. We don’t try to replace design or the CAD tools. We try to facilitate a seamless handoff between design systems and PLM to aggregate the entire product record together and enable all the teams to collaborate more effectively.
Michelle, I want to go ahead and turn it over to you now. Expanding on what Bill has just shared, how does structure and system control affect the production side of the business?
Michelle Lee:
The production side is little more informative. It has more requirements. Currently I make sure that also we have all the RoHS compliance information on all of our parts. We have the visibility of all of the change history of per the lifecycle. We have, let’s say, five lifecycles that mean a different project task in our project scheme of things when we release from new product introduction to going into actual production.
We also have evolution of all the lifecycles by date that we have to meet, so we can meet our production requirement and release date that goes into Salesforce. The information of changes is great, because we have access to redlines of each change as you go along in the history. You have redlines of anything that’s changed on the item summary, and on the AML, which is real critical for our contract manufacturers to see what is the most current approved part number that needs to be bought from a certain manufacturer.
We also have real-time access to our quick-start guides for our technical support guys out in the field. They log into Arena, download the quick-start guide, and are able to install the actual product that needs to be installed at that site. The collaboration is actually real important for our actual products that we buy from certain manufacturers and our contract manufacturer. With the notifications that go out through the workflow process, they get notified on a daily basis going through the stage one, stage three parts changes in the ECOs.
What we also do is the deviations get documented and collaborated with all the contract manufacturers that we need to inform. With this review of all of the information and educating our CMs, we’re able to have less, I want to say, scrap understanding of the product, et cetera. They usually contact me if they have any issues of any kind of accessibility. That’s about all I can think of right now. The turnover of suppliers’ employees is high. I have to educate on a yearly basis, because we do implement new functionality of Arena on a yearly basis. It’s real important to always train your suppliers.
Scott Reedy:
I agree. You talked a little bit about identifying the issues or problems and being able to provide better customer support. How in Arena are you able to go about the identification and solving the various issues that come your way?
Michelle Lee:
Well, a lot of times we might even have a certain problem that we have had before with another product line. With the quality control CAR system that we have, we’ll be able to search and see if we’ve had that problem prior. We’ll be able to resolve the issue in a quick, timeless manner because we’ve done this before. We’re able to maybe do a deviation, and do some extra testing, or different processes within our manufacturing process to correct this issue that we’ve had. That’s what’s so great about the history of the CAR system in your current product.
Scott Reedy:
Great. That’s one thing I’d want to let the audience know, as well, is that within Arena PLM you have the ability to connect a product record to the quality record. Whether it’s a corrective action request, or a CAPA of some sort, you have the ability to track that issue, help figure out what’s the root-cause analysis, and then go about correcting that issue. That’s great.
Michelle Lee:
The other thing that’s really nice about the CAR issue is that we are able to forward it onto a change request, and push it to an ECO, so it all gets resolved in a nice workflow.
Scott Reedy:
You have that nice closed-loop process which I like. Great. We’ve established that control’s important, and it’s not a bad word that some people may think about when they think about being controlled or under control. Our customers really do demand a high control and high security. If they’re managing their product, intellectual property, they want to make sure that that’s not violated, and that they control who has access to it at any given point in time.
As I mentioned, Arena brings this all together. When we bring the product record together, that’s going to include the electrical side, the mechanical side, the software side, documentation, specifications, SOPs. We bring everything together in that single source of truth, and then leverage it through the Cloud so that teams can collaborate 24/7 around the world.
For our second poll today, I’d like to ask the following. How do you view system structure and control in your job? For those in the audience, when you think about your job, do you embrace systems that add control? Do you find them helpful, but maybe it slows design innovation and you view it more as a necessary evil? Do you try to avoid using systems that require too much structure? Go ahead and lock in your responses, and we’ll publish the results in just a minute. (SILENCE.)
Think we’re close. We’ll go with a few more seconds. Let’s go ahead and publish those results. The nice thing is that I think we have a pretty progressive audience. I think that most people are embracing systems that add control. They see the benefits of having a controlled process. We still see some, though, that view this as a necessary evil. Maybe they’re concerned that having too many controls in place are going to prohibit design innovation and creativity.
Then we have some people that definitely try to avoid systems. Hopefully today we’re going to try and dispel some of the myths associated with control and structure within a product development environment, and hopefully help you see what we view as being the advantages to systems like Arena. Now I’d like to start with Michelle this time. Michelle, we’ve established that structure and control speeds new product development, and that sometimes seems a little counterintuitive, I know.
Given your involvement with the product and the change management process, how is accountability enhanced with better system controls?
Michelle Lee:
What the systems controls do is the PLM system actually has to go through a change order process to ensure that everybody signed up to that change. Through my, I want to say, change control, I have stages that the workflow goes through for approvals of change orders. Not only just approvals of change orders, but the implementation of the change order. It allows us to understand: How are contract manufacturers going to implement it? Are there any issues? Are there any software issues with a manufacturing tool, et cetera, that needs to be updated?
It’s just a collaboration of all kinds of information that allows you to manufacture at a faster pace and a streamlined pace. We go from new product introduction through in-design, to RTP, to now we’ve created a pre-production, and it has to have certain qualifications. This trail gives us an information of how we went through to release it to production. What were the dates they were effective? Has our contract manufacturer met those dates?
Then what happens is you have visibility within Arena to show those changes. Who signed it off? What date did they sign it off? How did it go through my staging process through the sign-off? I can also see how long it’s taken me through my reporting tool to see if I meet my average of five days to get an ECO all the way implemented. Am I getting faster results from my people that need to sign it off, or the CM?
Also, we do sometimes skip some of the lifecycles to make it a faster pace, because it doesn’t need as much qualification through the product development. We might skip pre-production. That way we have it documented. If we skip, go from release to procure, to in production, we know why, because those product lines don’t require that.
Also, I also have dates and times that I’ve actually captured all the integration information that goes into our ERP system. I’ve captured the date, and it’s actually validated in our ERP system. I know when it went in, and it should be effective, so there is no, I want to say, delay in ordering parts on a PO or ordering SKUs that we need the CM to build.
The visibility is real important. I give access to my CMs to mostly everything, the work in revision, so they can see the redlines, and also give them a lot of access so they’re able to produce the products that we have on orders, so there is no delay. Then with the CARs and the deviations, we’re able to track these temporary changes, the dates, what the serial numbers were of those deviations. There’s a lot of information you can capture and it does not take any time at all.
Scott Reedy:
I like what you said about having that flexibility. We talked about controls and system controls, and you also talked about the fact that you can skip a phase, maybe pre-production. There are reasons why you need to do that. You need to have a system that is flexible enough to allow you to move outside certain boundaries so that you’re not locked into a process when it doesn’t make sense.
One of the things I was curious about as you were talking is that sometimes when you work with contract manufacturers mistakes are made. We’ve touched on that a little bit earlier. I wonder with a system where you’ve got audit trails and that increased visibility, have you been able to avoid that contract manufacturer finger-pointing that goes on when mistakes are made?
Michelle Lee:
I’m trying to think if we’ve had any mistakes recently. Actually, we’ve cut down on a lot of mistakes. I think the training of our contract manufacturers to show where that information is, so they can access it anytime, is real important. You’ve got to be involved with them. You’ve got to have it seamless as possible. They are willing to learn. Even though they might run on another PLM, they still have to transfer the right data into their system. That’s real important to keep that relationship real clean.
Scott Reedy:
True. Great. Now, I’d like to go ahead and turn it over to Bill. Bill, your teams operate earlier in the product development process. Often we find that’s a little bit looser, maybe less control. There tends to be more emphasis on creativity. How do you view accountability during the early phases of product development?
Bill Orner:
I’ve found that you need to embrace accountability and make it work with the right balance of freedom and control. There’s a natural, logarithmic, increasing level of control as you progress through the NPI process, production, sustaining, and EOL, necessary and beneficial. You need to educate your team and structure your processes so they flow from less to more control when needed. I’ll go into that in a second.
Some examples with lifecycles are very early on in the design process you want no ECO control of any kind. This is during the design phase. BOMs can change hourly, daily, and it has to be quick and fast. This might actually address some of the concerns that people had in the poll earlier, where they had concerns about the controls that PLM might offer.
Bill Orner:
This is one of the key points is it’s not a burden to the engineering staff. Change your BOM as often as you want during that design phase. When you get into proto, you can have self-approving ECOs. This is where you start to capture tribal knowledge. We’re making a change from X to Y. I write the ECO myself. I approve it myself, and that knowledge is captured. Ask me in two weeks why that was done, and I won’t remember.
During EVT phase, we might have change control boards of one. I decide I have to change something, you approve my ECO, and it’s done. It’s fast. Then when you get into mass production, obviously things have very large ramifications, so you need very thorough ECO control, very large cross-functional teams. A very casual change that someone might think is insignificant can have massive implications as it ripples through the whole supply chain.
Scott Reedy:
I’m sure some of you in our audience have experienced that in the past. I know I have. I’d emphasize that it really is not an all-or-nothing proposition with regards to implementing control. The key is to provide product teams with the flexibility to apply the appropriate level of control during each phase of a product’s lifecycle.
One thing that we find helps teams overcome any concerns they might have around greater control and accountability involves the added business insights you get by having all the product data and the process information managed in a single solution by PLM. With analytics, we can provide added visibility and insights in areas like new product development, new product introduction, quality corrective actions and resolution, product project performance, and overall change-process cycle time.
This helps you to identify trends, gain critical product process insight, and also make more informed business decisions. For our final poll today, I’d like to ask everyone to go ahead and lock in all of those answers that apply to you. There are quite a few systems here to look at. What systems does your company have in place today? Do you have computer-aided design, computer-aided manufacturing, computer-aided engineering, product lifecycle management, quality management systems, enterprise requirements planning systems, or ERP, MES systems, and/or any other homegrown systems or repositories?
Go ahead and select all of those that apply to your company. We want to get an idea as to your environments, how complex they are today. We’ll give you about 10 more seconds to lock those answers in. We’re just about ready. Give you a little more time, because I know there might be some of you that need to add many of these different systems. We can see that a large portion of the audience has CAD systems which we would expect, and also CAM systems, along with computer-aided engineering and simulation.
A fair amount have PLM systems, which is good to hear. Over half of you have quality management systems as well. Over half have ERP systems today, and I think that ERP has changed in the last decade or so as we’ve gone to more outsourcing and contract manufacturing. A lot of companies no longer need to have that full ERP capability in-house. Sometimes that’s handled by their manufacturing partners. Then also MES systems and other systems.
From my vantage point, I think that this indicates that there’s really no single system that does everything from design through manufacturing. PLM really fits in between both the design side and the production side, and acts as that bridge or the glue between those two disciplines. Michelle, given your thoughts about getting more people involved in the process, including your supply chain partners, and the value of controlled data and accountability, can you share a little more about your experiences with systems, whether it’s PLM, quality, or manufacturing systems, and what’s worked for you?
Michelle Lee:
Yes. It’s always optimize all the systems you have and make them work together, and write processes so they do work together, and you have a documented process. Currently we have another project software, but we coincide to use that to release our projects that go from in a new product development, to production, and we were able to track it. Through that process, we use Arena to go through those lifecycles, so we have date stamps and it’s communicated to our contract manufacturers. They’re still in the loop. It’s real important to have them in the loop.
The integration, we have it integrated to our ERP system when the change order goes through. It actually uploads all the information, so I’m not touching the data in the ERP system. Real important for data integrity. The system we use with the integration also stamps the activity date, the change order number, et cetera, so we could track back to Arena and find out what made that change.
The other thing is you’ve got to train everybody as much as you can. When there are new releases that Arena sends to us, I’m always reading, going to their training, and their updates, and then I communicate it to my user group. Because it’s real important to get everybody as educated as possible in all the functionality, so we can optimize using the system at its fullest.
The product release process is real important for us because we go from, say, in-design to in-production like in six months—really fast. It really ramps up when we go into production. We go through the different lifecycles to eliminate any problems that we might have with sourcing, any kind of part that doesn’t meet requirements. Getting it through the real process of testing, software development, et cetera. It really enhances your ability to capture, and that release process is real important to go back to, so you know who approved it, when he approved it, and if it was implemented at your CM.
Scott Reedy:
Great. I like what you talked about, especially when it comes to integration. With ERP, I think that it’s important to realize that once you have everybody’s buy-in and they’ve approved a change to release a new product or make a change to an existing product, and be able to pass that instantaneously over to ERP so that the production side can start to take action on, that is great. That really helps to streamline the process.
Bill, I’m going to go ahead now and ask you for some of your recommendations. You use Arena at GoPro, and you’ve had experiences with other PLM systems and engineering design systems. What insights or recommendations would you offer?
Bill Orner:
First off, don’t over-design. Focus on getting just the right information that you need in your PLM system. If you overcomplicate the amount of information you want to collect for parts, it’s going to make the system more difficult to use. It’s going to take a lot more time to add new part numbers. I can’t say enough about using manual steps to transfer your BOM into your PLM system. Nobody should ever, ever be doing that.
If anybody is doing that out there, we need to hit you with a virtual stick somewhere. It’s just bad. You’re absolutely going to get mistakes. I’ll just interject, one comment I always tell people is, “I need to use smart people to do smart work.” A lot of repetitive data transfer, you’re costing the company unnecessary money, and you’re not making the best use of.
Absolutely focus on getting the right information at the right time. Use images for all the parts in Arena. This was just like I fell off my chair when I first saw this function in Arena many years ago. Use commodity codes. Put all your datasheets and vendor information in there. It’s really easy to do. Again, it’s all part of your tribal knowledge. Be consistent and appropriate with part descriptions. This’ll make your searches much, much easier.
A great example of this is finding connectors. There’s no good way to create descriptions for connectors. When you have a picture of a connector, it makes your life so much easier.
Scott Reedy:
You talked about using images in Arena. I don’t know if you’re referring to thumbnails, but can you elaborate on that a little bit so the audience knows what it is you’re referring to?
Bill Orner:
For those who don’t know, in Arena you can put a thumbnail picture on every part page. Very quickly when you get up to that part information page, you’ll see a thumbnail of what the actual part is. You don’t have to go to another tab, open the datasheet, see if that’s the right part. It’s super fast, particularly if you’re spending a lot of time looking through stuff, cuts down your fatigue.
Scott Reedy:
I agree. You also talked about transferring information like bill of materials from design to Arena, and how you really need to automate that process. Can you tell us what you’re doing and explain that a little bit more?
Bill Orner:
Yeah. I’ve actually done this at three other companies in the past. One of the leading vendors of electrical design tools, whose name I won’t mention, but is here in the Silicon Valley area, has an offering for their schematic design tool. Integrates very, very cleanly into Arena. When you’re in the electrical design process, you can actually specify parts in the schematic directly.
When you do that, you get the benefit of things like being able to do real-time costed BOMs out of your electrical design tool, instead of having to go through a very lengthy process of transferring it into Arena, rolling up a costed BOM. There’s also lots of other mechanical information, footprints, other requirements, electrical specs that you can transfer out of Arena into the electrical design process.
Scott Reedy:
Great. That really speaks to what I talked about earlier, which is making that handoff simple and seamless between the design systems and the CAD tools and Arena, and then later with the ERP as well. I’d like to go ahead now and before I turn it over to our moderator to address questions, first I’d like to thank both Bill and Michelle for their insights and recommendations today.
I’d like to just maybe leave these thoughts with you. As you consider your own development processes today, maybe ask yourself how your design and development projects are controlled. Can you easily share and securely collaborate with both your internal and your external product teams, or are you having to rely too much on key individuals? It’s getting back to that concept of depending on tribal knowledge versus a system.
Then what short-term or long-term actions might you be able to take to accelerate new product development, and new product introduction? Are your approval processes appropriate for each stage of development, or is there some flexibility or maybe too much control currently? Do you and your team have visibility with the other key teams throughout the product lifecycle so that you know what everybody’s doing, and you’re able to bring the entire design together seamlessly?
Then finally, do you have a single system to manage all this information, or are you going to various repositories and different servers, and different systems, and really having a hard time knowing where is the latest, greatest information for the entire product record?
I want you to know that everything we do here at Arena is designed to help companies design, produce, and improve innovative products quickly. We provide better control and accountability to help eliminate errors and speed the time to market, especially for today’s products. Now, I’d like to turn the time over to Murray. He’s going to go ahead and address any questions from the audience. Take it away, Murray.
Murray Slovick:
Thank you. A few of you have already submitted questions. We’re going to jump right in. If you’d like to submit a question, type your question into the question window on the side of your screen, and then hit the submit button. While we are answering your questions, please complete the feedback form which is located on the bottom of your screen. First question, if you are using a third party to do manufacturing, how do you transfer data to them?
Bill Orner:
I’ll respond to this. Ideally you want to have them set up as a third party in Arena with a vendor account. These are easy accounts to get set up through Arena. In the example that I gave earlier with the CM, where we ordered the 10 prototypes, we went to them to set them up with a vendor account. We actually found out that they had already been done from another customer. All we had to do was enable their account with access into our BOM.
The other thing is you can send them a PDX. You want to get out of the process of using anything that’s email-related to transfer information to your contract manufacturer or third party.
Scott Reedy:
Great. Michelle, I don’t know if you have any input as well.
Michelle Lee:
Yes. It gives the ability to when you do give them the access as a vendor or supplier, et cetera, as Bill mentioned, it gives them the ability also to download a bill of material and set it up in a CSV and upload it, depending on what their accesses are. They’re able to get to it quickly and implement it quickly from your system to theirs. It’s real important to set them up, give them accessibility.
Because what happens is then if they’re doing a third-shift build, they’ve got to have access to it. You might not be around. It’s like Bill said about tribal knowledge, it’s not tribal knowledge. It should be accessible 24 hours a day.
Murray Slovick:
Our next question is what would you share regarding best industry practices for product lifecycle management?
Bill Orner:
Michelle, why don’t you take that first?
Michelle Lee:
Well, we have a lot of lifecycle management on my end, but we do go from in-design to, like I said before, release to procure. When we go to release to procure, we give access to our suppliers, so they’re able to get some prototypes built. There’s limited buys, et cetera. This way when it’s RTP’d, it gets into the ERP system so they can also process purchase orders or sales orders against those parts.
There’s, like I said, limited buys or limited sales orders, but it gives them accessibility at RTP. Then we go from RTP to pre-production. The pre-production is more for full unit testing, and ensuring the software is working correctly. That way we can, when we release to production, we’ve met all these milestones within the product lifecycle at pre-production.
Then when we meet that, we go to production, and everybody’s aware of the pre-production. The sign-off and implementation cycle is a lot faster, because you’ve met all the requirements between each one of those lifecycles. Then in in-production there is a lot more sign-off, but because we’ve met all these other lifecycles, people have the knowledge and the understanding of the information and Arena is correct, and it’s ready to go to production.
Also, you got to remember, you also can make everything deprecated or abandoned. If you don’t use it anymore, you can change your lifecycle of that so nobody actually buys it, so that lifecycle gets blocked in my ERP system when it comes across. Then we don’t have any buys of inactive material.
Murray Slovick:
Our next question is directed to Bill. The listener asks, connecting Arena into the engineering design environment seems like a lot of work and possibly dangerous. What has been your experience?
Bill Orner:
My experience is this is a huge time saver. I can’t say enough good stuff about it. You can go from a lightweight implementation if you desire, to a very heavyweight integration. The connections now are very mature going into many of the popular design tools. You don’t need an IT staff. You’re not inventing new things. You’re not writing custom software. It’s really straightforward. Once the design engineers see how it works, they’ll never go back.
Murray Slovick:
Next question is for Michelle. The listener asked, there is always some resistance to change in any company. How have you overcome that and what tips would you offer?
Michelle Lee:
I think the biggest thing to get everybody to buy in is the efficiency and the timeline it takes to get everything from in-design to production is a lot smoother in a PLM. You can get it up and manufacturing much faster and ensure correct data. We have a very fast NPI to production, and we’re always releasing things on a quarterly basis to get it out in the industry. Then as soon as we get it released it goes into Salesforce, so it’s available for our customers.
I can tell you that change orders and controlling your data averages five days for me. I have over 10 or 12 approval processes. Everybody within a certain department has certain criteria before they sign it off. I’ve got every department agreeing to what they have to implement at the production lifecycle. It doesn’t take, to me, any longer.
Actually having time stamps and capturing the information of that change order approval process, and then implementation for the CM. I can document and find when did that CM say they were going to put it on the factory floor. I can go back. If they didn’t do it at a certain time, guess what, I’ve got my procurement guy on them.
Murray Slovick:
Listener Brad wants to know, how do solutions like Arena support ISO 9001 processes?
Scott Reedy:
Michelle, maybe you could take that.
Michelle Lee:
We have not gone through ISO, but we do connect. I can’t think of the term. We went through one process where I was able to capture all our procedures for… I can’t think of the certification that we got. For every department, they have, I want to say, work instructions. We’ve gone through Arena, released them through a doc control process, where only the departments sign it off. Then it’s time stamped, and it’s captured. It’s available. It meets the ANSI standards of all the history of files and when the changes came about.
There’s a lot of, I want to say, controls in place in Arena that meet a lot of that information just by using workflows and timestamps. The timestamps are available for you to run reports on. You could find out when it went from this lifecycle to the next. When did I release this procedure? When did we implement that procedure? When were the different revs, those dates? You have a lot of audit trails for ISO and those, I want to say, procedures that are required for every department.
Scott Reedy:
I’ll add a few comments. Let me add a few comments, if you don’t mind, Murray. That is that having worked in engineering services before and having gone through ISO 9000 myself, and then also working with a lot of companies that do this, there’s a few things in Arena that are really nice. One is that you have Arena training. You can actually manage your SOPs, how people are changed, and make sure that they’re all able to do their job. The auditors love that.
When they’re able to come in and see that everybody’s been trained on the appropriate SOPs, it really checks the box for them to be able to say that you’ve got a controlled system, people understand how to use it, and the processes are being managed properly.
I think at the end of the day that being able to manage all of your product information along with those processes in a single system, again, the auditors find that that’s very critical when it comes to having a controlled process. They’re not going to run into a lot of problems. They’re not going to run into issues where maybe there are hard copies of documents or procedures lying around in different departments or on the factory floor. They’re able to go to a single source for all that information and see who’s been trained and when were they trained.
Murray Slovick:
Listener Dave asks, if dealing with an original design manufacturer (ODM), does their design data flow as easily from them into your own Arena system?
Bill Orner:
I’ll address one part of this. I assume what you’re talking about when you say data flow is from the customer or the company who’s having the ODM build the product into the ODM system, not the other way. Because generally, this is a unidirectional transfer of information. There are things like PDX, CVS, and Excel, that are very standard output formats from Arena and easily digestible on the ODM side.
Currently, at GoPro, we’ve captured some of the ODM’s standard part numbers in our Arena system as additional fields. We’re designing based on our standard parts, but then when we go to transfer a BOM, it can already output it in that ODM’s part-number format. That’s a good way to address standard parts.
Any products that have custom-made or custom-built components including hardware, molded parts, and plastics, will have a unique part number.
Scott Reedy:
I’ll just add a clarifying point. He talked about these different formats for transferring information. One thing that we do at Arena is we do provide the build packages or PDX, which is product data exchange packages. Basically, it’s an XML file. It has all the product record information, the drawings, all bundled up. Then, using Arena Exchange you can actually share that in a secure manner with your different partners. They can actually collaborate around that.
It’s a nice way to be able to share information, and it actually doesn’t allow or require the partner to come directly into your database. It can actually just go out there and look at the actual build package, and then either maybe submit a bid, or maybe just download the information so that they can execute from a manufacturing perspective.
Bill Orner:
Scott, you should add that PDX has been around a long time. This isn’t some Arena-specific invention.
Scott Reedy:
That’s true. There was a consortium that I won’t go into the gory details, but I was around back in the late ‘90s when this consortium got together and had to develop this agreed-upon format. There were a number of manufacturing companies, suppliers, different OEMs. They all got together and agreed on this one format so that you could share product information across various systems. Good point.
Murray Slovick:
Our listener Kenneth asks, updates from Arena sound like it could be a problem if someone has to monitor it and forward it to users and retrain personnel. How stable is the tool and how often do updates get rolled out?
Bill Orner:
If I can interject on this one. This sounds like somebody who might have been an SAP customer in the past. I’ll just say, and Michelle could probably add a lot more color, because I’m more on the front end, engineering end of it. I’ve been using Arena, I think, nine or 10 years now. The way that the updates have been done, there’s a baseline set of functionality that’s always there. They’re not making radical changes to how that baseline functionality works.
There are things that are done that are cosmetic improvements, or improve the flow of the tool to make the user experience easier. Then there’s functionality that’s added on top of that baseline. It’s not like you log in tomorrow and all of a sudden the whole thing is completely different, and you just stare there lost, not knowing what to do.
Scott Reedy:
That’s a good point.
Michelle Lee:
What I do too …
Scott Reedy:
Go ahead, Michelle.
Michelle Lee:
What I do too, when Arena comes out with the quarterly updates, I believe, on your software, and there’s some new functionality, I send that around to all my users, and inform them of any new functionality, and any new screenshots, whatever they’ve added, and go through a little training with them to show that functionality. They might find something they can use, and it makes their life a little easier.
There’s a lot of things always added. There’s always a lot of nice new updates that are actually done on the user requests. I’ve requested things and Arena’s implemented them, and it’s made my life a lot easier.
Scott Reedy:
Appreciate that.
Murray Slovick:
Our last …
Scott Reedy:
You know what …
Murray Slovick:
Sorry. Go ahead.
Scott Reedy:
Let me just add one more comment, Murray, if you don’t mind. That is that speaking on behalf of the vendor or the SaaS provider in this case, we’ve been doing this since 2000. We’ve had to really refine that process over the last 16, 17 years. As they both touched on, we’re going to make sure that there’s adequate communication. You’ll know when releases are coming out. You’ll know what’s going to happen in those releases. In a lot of cases you may not need the functionality that’s being introduced. You decide whether or not you’re going to take advantage of new functionality or features that we introduce.
Scott Reedy:
It’s always going to be something that we focus heavily on, which is making sure our customer base knows what’s happening, that we provide webinars and training and videos so that they’re able to use and take advantage of any new functionality that we release.
Murray Slovick:
Our last question is directed at Michelle. There was a little discussion on quality processes in your introduction, and your experience with eight-step corrective action processes. Are you using Arena today for quality management? If so, can you share how quality management fits into the product development process at your company?
Michelle Lee:
Actually, we use the CAR process. It’s an eight-step process. We do not use it for product development. We use it after the product’s released. It’s more for communicating we have an issue with this part. Do we do more first articles? Do we move it into a MRB location, and reevaluate it, and contact the manufacturer of that part? Do we need to do a deviation so we can still use that part?
The CAR process we use is more for the manufacturing side. We’re able to document that corrective action that needs to be done, and have an audit trail from corrective action, to deviation, to change order. I don’t know if that answers the person’s question, but I don’t use it for product development, because I’m in the manufacturing side.
Murray Slovick:
Well, that concludes today’s presentation. On behalf of Electronic Design, I’d like to thank Arena for sponsoring today’s event, and of course all of you for joining. Have a great rest of the day.