Okay. So, yeah, as Scott mentioned, this is what we're talking about. I am Priyanka Ravi. I also go by Pinky, and I am a developer experience engineer at Weaver Works. Those are my puppies. Just any chance to get to show them off. And then, okay, so I'm going to basically be treating this as kind of like a little story time session. I'm going to be sharing some user experiences, mine included. And so I've interviewed a few people. Some that are actually speaking here today, which is kind of cool. And I'm going to share those with you as well. So, first up, it is my story. So I actually only recently joined Weaver Works maybe like five months ago. And before that, I was actually working at a large insurance company in the U.S. called State Farm. And at State Farm, I actually was part of a small team that was called the delivery engineering team where we implemented GitOps from scratch. So it all started a long time ago. When I first joined State Farm, the way that code went into production was very tedious and time-consuming. You had to go to a vendor tool and submit a request, and then your manager would go and approve it, and then there would be like a change window. And if you were lucky, it would take days to get into production, but more likely it might take a week or maybe even a couple weeks. So definitely not an ideal solution. I'm sure that story is not alien to some people. I'm sure other people have been in that situation. But eventually, there was another option introduced at the company that we called the automated software change option. I think it was using urban code. And that reduced the time to hours, which was great at the time.  Sorry. That's probably way better, okay? So that made it a lot. That made it a lot, obviously a lot quicker to get to production, but we could do better.  And he came back talking about this thing called getups. And this was like a few years ago. And he was like, wow, this thing sounds so cool. And, you know, we're already using, we were using GitLab at the time. And we might as well just take advantage of that to meet our compliance standards and, you know, make the developer's lives easier. And it's fast. So we ended up forming the small team at the time, just three people. And we, you know, we faced a lot of pushback at first. There were people in the change management space, right? Because in insurance company, there's a lot of auditing. And they also had a bank. So there's a lot of financial stuff as well. And they said, oh, my goodness, you have to meet so many compliance requirements. And we can't actually go this route until you meet all of these requirements. And so we created a lot of tools internally, such as like CLIs to get things into the config repo. And then we also used Terraform to create those config repos and keep them locked down so managers could approve in there. And that whole process was a lot of work to meet those requirements. But eventually we did. Then we heard from managers, well, we don't actually want to have to log into GitLab because we've never had to do that before to look at code. And now you're telling us we have to go approve merge requests. And so that was the next step. And but the thing that really kept us going is that on the other hand, we heard from developers, if you can make this work, then you'd be our heroes because this would simplify our lives. We don't have to go to a separate tool to get approval and all that stuff, right? It's all just in what they're used to. So that kept us going. And eventually we did get it set up. Actually, the first platform we were trying to get it set up for was AWS, not Kubernetes actually. And so we set up all these tools and everything. And then Kubernetes was the next piece that we tackled. It was very exciting because we actually, that was my first introduction to Flux. But the challenge there was a new one where at State Farm, Kubernetes had already been in production for a couple of years. There was a team that was the dedicated Kubernetes platform team, and they had been doing this for a while, right? So we're trying to come in and be like, oh, let's change entirely how you're doing what you're doing. We're going to change the way that namespaces get created. We're going to change the way that users get onboarded. I mean, that's not going to be an easy conversation, right? They're not going to happily be like, yes, please change our process. So we had to do a lot of work with them. We did a lot of proof of concepts to show them that it wasn't so bad and that this is a very simple thing to do. And at the same time, there was already a UI in place to get new people onboarded. That was the way that they had been doing it, and then it would call off to the API and do all these other things, right? So we just used the same UI to then create, like it was a pipeline to create the YAMLs for the Flux multi-tenancy repo to create those new namespaces. So that Flux could then pick it up and just create those namespaces. And that at least made them feel a lot better because then the users that have already been using that whole way of getting onboarded onto Kubernetes at the company didn't feel any difference, right? They don't care how it gets created as long as it's the same experience and it does get created. So that also helped bridge that gap with them. And eventually, they actually were really excited about it and they took ownership of it too. So that was like a great accomplishment for us as well. And I want to add too that, well, I don't know what's happening at the bottom, but I want to add too that we would never have been able to do it as quickly as we did. We got it up and running within, we got get-ups going within a year. It wouldn't have happened if we didn't have leadership buy-in. I think leadership buy-in is a huge thing. It's a great asset to have if you can get it because if the leaderships are telling, if the leaders are telling teams that, hey, this is the direction we're going in, things are so much smoother. Otherwise, it's a lot harder to get different teams to buy into this aspect as well, to make a change because they're like, it's already working. Why would I want to even do that? So that was my experience. The next one I want to talk about is actually kind of funny because if you're at my talk, you're actually missing her talk. And so this is actually App Flyers, their experience. And so if you, like, since you're here, I really encourage y'all to go check out I Let's Talk online later. If you get a chance. So basically with App Flyer, their company just exploded. They got really big, really fast, and their infrastructure grew exponentially.  So because it grew so fast, their developer experience started to deteriorate. They started to have a lot of pain points, such as fragmented work, the developers needed to go through multiple resources and services for a single commit. They no longer were independent, and they had to actually get help from the platform group to do any actions. So basically what they did is they created a cross-platform team because they had seven platform teams in their platform group. And they had representatives from each of them, and they actually used Flux in the base, and then they added a bunch of additional custom tooling on top as well. Like I said, I really recommend you check out her talk to find out more about how they actually did it. But their initial reaction to GetOps was not the same experience that I had. Theirs was not fireworks. It was actually, the developers were not excited about it at all. They were actually very apprehensive of it because they didn't like the fact that their environment was changing and the way that things had to go were different suddenly. So they actually solved that by using different representatives from each of the R&D teams and basically created this champions group. And then they were able to then go back and take that back to their teams as well. As well as they actually had leadership buy-in as well. So their CTO actually did a talk and everything about GetOps being the way to go. So that also helped make people realize like, yes, this is the direction we should go, and they felt better about it if they heard their leader saying it, right? And for them, building out their GetOps solution actually brought on amazing results. It reduced all their developer pain points and increased the number of developments per minute for them as well. So that's very exciting. So another one I want to talk about is, so this user is someone I interviewed that actually works for a SaaS company. So interestingly, when I was talking to them, I got their company perspective as well, but I also got to hear some of the stories that they've seen other people have as well.  So they didn't even have GetOps in place at all and not Kubernetes. So they created a team, a dedicated team to start Kubernetes, but they had the opportunity to actually create GetOps alongside Kubernetes. And their end goal is to actually have everyone on Kubernetes using GetOps as well. So they actually said that they like Flux because it's a set and forget type thing. You just kind of set up Flux, point it to something, and then you can kind of forget about it. But one thing they said is that they've seen some really crazy pipelines and setups for deployment that are ridiculous. I'm sure you all have heard of some similar ones like this, but just really over engineered. Basically, this one was, so they were using Terraform to set up their infrastructure, which is not uncommon, right? Where it gets really crazy is that they were using Terraform basically to what it was doing, it was creating, sorry, I have to read this, because it's not something I could even memorize because I can't wrap my brain around it. So basically, the process to create it was literally pushing the code to a dev branch that then gets built and then there's a new Helm chart with that version that gets created and then that just stops. And then they merged that into some other branch, which then did the entire process again, except this time it actually deploys the Helm chart. It was insane. It's a crazy process. I'd never heard of anything like that, but I've heard of some other situations similar. So getting something like that into production, literally even a simple website UI took them an hour. After they told me about that, their next words were literally if they had been using GitOps. Everything would have been a lot easier for everyone involved in that situation, right? And they had also helped another one of their customers who was using Kubernetes, but they were super new to it and they were doing manual deployment. So they nudged them gently towards GitOps. And one thing that I thought was really neat is that these people had not actually been using Kubernetes very long. They were very new to Kubernetes, but they pointed out that even they were able to wrap their heads around the concept of GitOps really easily, which was pretty exciting to hear because it makes me happy that it's not so convoluted that people can just understand it even if they have a basic understanding of Kubernetes. So anyone can really do it. Yeah.  I think what they said is they keep hearing this misconception, and I've heard it too, is basically GitOps is just the deployment part of it. It's not the whole CI process. So all those tests and scans and everything, sometimes people think that they get a little confused of like what does Flux do or what does like any of these GitOps tools do. And so by that point, by the time Flux comes along, the test scans, all of that should already be done. So that part is just the continuous delivery part. And I just wanted to emphasize that. So now I want to see if there is anybody in the audience that has a story they want to share because we have some time. I think I've got a story to share. Okay, cool. No, this was totally not staged at all. Just wearing a mic. Just by chance I have a mic already. So yeah, I figured, excuse me, I did share a little bit of my story. I know I just gave a talk a little bit earlier. And so some of them I've already heard the story before, but so sorry to you all. But previously I was working at Virginia Tech. And at Virginia Tech, we were building a platform just like this. Many of the stories that you have just shared with us. And GitOps was a good separation point between the platform teams and the application developers. And there's kind of two things I want to bring up that GitOps helps solve for us. When we first got started, we recognized that there was a missing piece of how do we provide kind of a web interface kind of thing. Because mostly the dashboards out there, if anybody's ever run a Kubernetes dashboard, good luck trying to present that to the lay person. And so we built our own dashboard that took a lot of the different components and kind of wanted to present it in a read-only manner as GitOps would support. But one of the things that we did with that dashboard was that we would highlight specific problems or things that were going on. So then it would kind of help nudge the application developers along. And one of the really neat things that happened out of that was since all the teams are using Git to version control their deployments, we started watching new teams that were spinning up. And we would watch them to see what was their journey of learning. And so we would see a lot of times that the very first commit is, OK, I deploy a pod. And OK, that's cool. They see a pod spin up. But they can't access the pod. They can't open up a web browser to it. And as part of our dashboard, we had a little bit of, OK, hey, you've got a domain here, but it's not connected to any pods. And so we kind of give them the next step. And we would see the next commit is, OK, here's a service. Here's an ingress. And we could kind of see that commit history as they're learning and going through that kind of learning journey to help walk them through that process. So in many ways as a platform engineer, using GitOps helped us kind of see where the common stumbling blocks for our developers were. And how can we help them out? Another aspect that we were pretty interested into is going to application developer teams and simply saying, hey, here's a platform. Congratulations. Now you have to learn how to write all this Kubernetes stuff. Good luck. And so we had a lot of developers come back and like, OK, I'm writing a service.  And what are these labels? And in all this stuff, and it was just so complicated. So we did a lot of experimenting internally of, can we use the compose spec? A lot of the teams are already using Docker compose for development. Can we use that same specification, add some extension fields and say, OK, for a port, here's an x-host field. And we can convert that and use something that they're already familiar with and convert that into the manifest that could be deployed on the cluster. And we had some pretty good success with that. I'd love to still do some experimenting with that. But I think there's some work as a community that we can do to kind of raise that abstraction level for the developer teams. But I think GitOps and this kind of this boundary layer between the platform teams and the development teams, it's right for a lot of really cool work and development there as well. Did we say your name? Oh, yeah. I didn't even say my name. Pinky's just like, you didn't even introduce yourself. So my name is Michael Irwin. I'm currently an engineering manager at Docker. But a lot of my experiences that I've been sharing today were about my time at Virginia Tech previously. So one thing that I really like about Michael's story, too, that's different than mine, is that they got to stand up Kubernetes and GitOps at the same time. So it was like the same team that managed both. And so the whole thing is like, if you haven't already stood up Kubernetes and you're here to get started with both, it's a great opportunity to get started with both. You don't have to retroactively fit GitOps into your existing Kubernetes structure, which is cool. If you have that opportunity, if you don't, I mean, it still works. I'm here as proof that that still is possible. But yeah. So that's kind of what we wanted to say, too, is you really can do this. We've both implemented it ourselves. And no matter how crazy your situation seems, there's a lot of really crazy situations out there. I think we've both heard stories that are insane in our time working with Flux. But it's totally doable. You can definitely make it work. And as I mentioned before, if you do get leadership buy in, it makes it so much easier. And then another thing that I forgot to mention with my experience is doing a lot of talks to actually help developers get started with it. I think that really helps. I did a lot of talks when I was at State Farm to actually promote it and then make people feel a little more comfortable with it. We did workshops. We did a lot of that stuff. So that really helps as well. Yeah. And then we have a Flux booth here. Nice shirt. Yeah. So if you do want this shirt, we have a bitly up there that you can go to and you can come meet us at the booth. And then we have these shirts as well. So we just wanted to see if there were any questions at this time. Not pre-planted questions. Yeah, this is real.


Hi everybody, I hope that you're doing well. If your aloe looks like this one, so you have leggy and droopy leaves, this video is for you. Today we're gonna be talking about why we get leggy and droopy growth, and how we can help our aloes. Okay, coming up. So the droopy leaves can actually be a consequence of a combination or one of the following factors. Number one, lack of sunlight. You know, I'm pretty sure that we're having this problem because of lack of sunlight. We actually have our aloe right in our bedroom, and our bedroom has a north facing window, which gets very little amount of sunlight. So this aloe actually started growing really long, and this is because it is trying to reach the sunlight. And of course, here in Berlin right now, we're not getting so much sunlight because we are approaching the winter. So it actually gets dark at about four o'clock, and the sunlight is not that intense at this time of the year. So if this is your problem, I would recommend that you get some grow light for your aloe. I'm actually planning to build a cabinet for all of my succulents so I can add some more light for them. And of course, I will put this aloe there. Number two, poor watering practices. Remember, the aloe is actually a succulent, so they retain lots of water in their leaves. And hence, we don't wanna water them too much or too often. What I always recommend with succulents is that we always let the soil dry out completely in between watering. So this is the same for your aloe. And in order to make sure that the soil has dried out, always check with your finger. So I always check the soil with my finger and with my succulents, I go all the way down just to make sure that it is completely dry and then I water. So usually, I water my aloe every two weeks or so, but always check the soil because this is also gonna depend on the environment that you have your aloe in and the region where you live. But again, always remember to let the soil dry out in between watering. Number three, you may have a fungal infection. This usually happens when we overwater our plants because the soil is very humid and our aloe cannot absorb all the water. So what I would recommend is that you check the base of your aloe and the roots. If you find that you have a fungi problem, I would recommend that you go to your local plant nursery and ask them about it. They're usually very friendly and they may know whether you need a fungus site and which one to use. Number four, cold temperatures. The best practice is to have our aloes in a room that is gonna be higher than 10 degrees Celsius. So 10 degrees Celsius is already not ideal. So make sure that the temperature around your aloe is higher than that. I think the cabinet that I'm thinking about for my succulents will also help my aloe with this. And this is because all the succulents will be protected in this cabinet with extra light and a little bit more heat. Number five, too shallow of a container. If the pot where you have your aloe in is too shallow, the plant won't be able to grow a very strong root system that will be able to hold her. If this is the case, make sure to repot your aloe to a deeper pot. And last but not least, pests. You know, we've been having some problems with thrips at the moment. And currently we're treating the problem, but they are very hard to get rid of. And when I was checking this aloe, I found some of them, not too many, but some of them. So some of the leaves that were actually more droopy, that's where I found most of the thrips. So if you have any pests, make sure to treat your plant as soon as possible. Depending on what you have, you may want to use different treatments. So for example, for the thrips, I'm actually using horticultural soap and neem oil. But if this continues to be a problem, I may have to go for something stronger. Okay, so now that we know the causes and how to help our aloe with these, I'm gonna give you a tip to give her an extra support while she gets better. This is going to help you in preventing that your aloe falls over. For this extra support, we will need some small bamboo sticks like these, a string like this one, and scissors. Okay, let's get to do it. Okay, you guys, so the first thing that we're going to do is try to carefully put our aloe leaves a little bit up in the center, so we can just support them with our hands, just like so. And then with our other hands, we're going to put the sticks all the way down and around our aloe, very carefully. Okay, so after this, we're gonna let the aloe be a little bit and just carefully set it down. And here is when we're gonna use our string.  And this is going to be at the bottom of the stick, like not right at the base, but more at the bottom. Then if you have leaves on the way, you will move it to the center and go around with your string. And again, go around the bamboo stick and make another knot there. So we're gonna do it like so. We're gonna try to make it as tight as possible. And if it flops again, it's okay because we're going to do another level again on top with the string. So this is just for the bottom. So you continue all the way until the last stick. Then we're going to cut and go one more time. So now a little bit more up, maybe here. And again, we're gonna put it up a little bit, all of them, so also this one. And then go around to the next one. I'm gonna put this a little bit more on the side so it has more protection. And we will make another knot here. This can be a little bit more complicated when we are making the knot and holding the leaves. But we just have to be careful not to hurt the leaves further, right? So we have to be very careful and gentle with this. So just like that. I think this one is gonna need another level. So I'm just gonna go, I'm gonna finish this one and make another one. So it has three levels of support. So there is our second level and one more. We're gonna start on this one so this ones are okay. So I'm just gonna go maybe here. But as you can see, the more levels that you put, the easier it is. I'm going a little bit faster now than the first ones. So the last piece of the string is here, so I'm just gonna cut it. And remember, this is just an extra support while we treat our plants. So this may be more sunlight, less water or some treatment for a pest. If you have any other tips to help our alos, please make sure to comment below so we can all learn together. And as always, I will see you in the next video. Okay, ciao.


Hello, thanks for joining us today for our OPEX webinar, improving project results using factory acceptance testing best practices. My name is Jim Krozan, Vice President of Content for PMI Media Group, and I'll be your moderator today. The factory acceptance test, or FAT, is critical to verifying capital equipment operability prior to leaving the supplier's factory. Unfortunately, FATs are often overlooked or underdeveloped in the early stages of a project. This leads to unnecessary costs, delays, and difficulties in later stages. This webinar will discuss the value and application of the OPEX Leadership Network's FAT work product through real-world examples. Before we begin, we want to give special recognition and special thanks to our OPEX sponsor, Metler Toledo. Today, we are joined by Steve Schlagel, Managing Director of PMMI's Operational Excellence Leadership Network for OPEX. John Uver, Product Marketing Manager for Metler Toledo. John holds industry leadership roles in packaging machinery safety and automation and was elected to the OMAC Board in 2018. And finally, John Giles, Managing Operations Engineering Group, Amway. John's team is responsible for specifying, purchasing, installing, and qualifying process and packaging equipment for Amway North America. At this point, I will turn it over to Steve Schlagel for a short introduction to OPEX. I will be back to take your questions for our speakers. A bit of housekeeping, if we do not get to all of your questions, we will forward them to the speakers who will be able to reply to each of you individually by email. Steve? Jim, thank you very much and welcome everyone to this next in the series of our OPEX Leadership Network webinars. By now, you may have heard of OPEX, but just as a matter of review, PMMI founded the OPEX Leadership Network in 2011 and it's a very dynamic community of manufacturing, engineering, and operations professionals from over 250 companies who come together and collaborate on solving the common operational challenges, facing the CPG manufacturers and their supplier community. As a result, we develop best practices and make all those best practices or protocols free for industry adoption. First, let's define what is operational excellence and we believe in the OPEX Leadership Network, it is a philosophy of leadership that drives deliberate and intentional and sustainable improvement by focusing on the needs of the customer, empowering employees and optimizing processes. So it's a holistic approach to operational excellence. Our group is being led by our executive council or our board of directors, if you will. As you can see on the screen, many well-known and recognizable companies in the CPG industry are represented in their leadership capacities from their companies and bringing their ideas and guidance to the OPEX Leadership Network's executive council. It is from this group that provides the insights and ideas and concepts by which we can ultimately develop best practices that we call by-industry and for-industry. So what that means is we have put it in three large buckets. First, the people. In the people, here we are focused on the human asset. So a couple of our documents that are available for free download, as first is the workforce engagement. This is focused on helping companies develop high-performance teams in order to drive improved performance within the manufacturing walls. Worker safety is another one. And another one that PMMI just launched is the packaging and processing women's leadership network. From a process standpoint, we have quite a few best practices and protocols available that touch on all ranges and areas to drive operational performance within manufacturing. And these range from OEE and food safety, sustainability, sanitary aspects of CIP, and even remote equipment access, which is just being launched into the market as we speak for peer review. And finally, from the technology perspective, this is focused on the capital spend. Where is, how are the best practices and protocols from many of these companies come together to help you improve those areas in the capital spend? And in particular, as Jim had mentioned earlier, today's focus is on the factory acceptance test. So the way in which we like to categorize this is these best practices and protocols can help your company, whether you are a CPG or a supplier, in the quoting and buying process. And to help you from a standpoint of reducing unit costs, OEE and sustainability can help in that regard. From a quality perspective on product safety and clean in place, and then certainly from a performance from workforce engagement, worker safety, and the remote equipment access. So that's a brief overview. You can download any one of these documents from the opexleadershipnetwork.org website, and we would certainly invite you to do that. And now on with the show, if you will, and I'm gonna turn it over to John Giles of Amway. John? Thank you, Steve, for allowing me to volunteer to do this webinar. And really thanks to everybody that's listening for taking the time to join today. As Jim mentioned, my name is John Giles. I'm the manager of the project engineering group for Amway based in Aida, Michigan. And my team is primarily responsible for identifying, purchasing, installing all of that capital equipment to support our Aida-based manufacturing facilities. So first I'd like to give some quick background on our involvement with the OPEX FAT protocol. Amway participated in the original CPSG team that was responsible for building the protocol that started back in 2014. Team was composed of representatives from multiple companies, and over the course of the year we essentially put together the protocol of content through the use of Webex conferences and then some file sharing as well. The final document was released in late summer of 2015. And at Amway, we conduct about 15 plus FATs every year, and that covers a wide range of equipment. We're looking at both process and packaging equipment, and we can be doing something from a $50,000 labeler to a $2 million filler up on the high end of things. Like many companies, Amway was looking really for a standardized approach to our FATs across our organization. And the development of the protocol tied in well with what we were doing internally. So that helped with our involvement. And then in addition, our customers and our group was really strongly looking for ways to improve our results and have better performance to help with our timing and our production startup with our new equipment purchases. So through better performance of our FATs, we really expected to positively impact our equipment startup again. And particularly looking at talk vertical startup and saying, hey, we wanna rapidly accelerate and get to our target performance levels. So we believe that by pushing a lot of that work back up front in the FAT and identifying that criteria and making those FATs successful, we can help with that startup. And then also, if you look at it from an OBE standpoint, we want this equipment to go in and to run extremely well when it gets integrated into the line or if it's a new line. And we felt like if we did a better job upfront, we can help with our results with production in higher sustainable OBEs from a production environment. From the timing standpoint, we found that really the planning for the FATs must start early in the process. And ideally, we're gonna do that during the RFP process. And if you look at the new RFP protocol that's available through OPEX, it also emphasizes that this is a key technical element for completing the RFP. And our findings definitely re-adgrade that, that we wanna be planning for that FAT upfront in early stages of the discussions with the OEMs. Then really general FAT criteria, we're looking at discussing that before we place the purchase order. And some of the main criteria that comes up can have a pretty drastic impact on any additional requirements, options on the equipment or other things that you would need to account for in your purchase order to the OEM. And then finally, the protocol has developed kind of that last step, but we look at the key for us has developed that with the OEM and communication there is critical. And we wanna have that done ideally before we get into fitment and pre-testing. So we're starting those conversations then and then have a finished protocol that we can send to that OEM already agreed upon ideally two to three weeks in advance of the FAT. So as part of the FAT protocol, if you download the document, you'll see there's a checklist in there. And that checklist is really put together to kind of help guide you through the process and really overall to encourage collaboration between the CPG and the OEM. It's not a prescriptive document, it can be changed, depending on the type of equipment you're dealing with, you may or may not check some of the boxes off. And then we've also found that this is a good project tracking tool, kind of helps us measure and monitor where we're at and are we doing the right thing as we progress through the project. Then this is the main cover sheet, Steve alluded to this earlier. So if you'll look for this document, you can download that on the website. And there's a lot of content in this document. I'm not gonna go through everything individually it would take way too long for this webinar. I will primarily be focusing on key, four key focus areas for AMWI. So the first one is staffing, then we'll talk about safety, pre-FAT and then performance. And again, those are all individual criteria areas within that protocol. So for the first piece under the planning section, we're looking at staffing. And staffing is always a big issue for FATs. And if you look at this, it's an actual screenshot from the protocol document. And what we're really looking at here is some, you'll see this template is followed in each section. So the first part we have a description and we're saying in this case, both the CPG and OEM need to develop the recommended participants in the FAT. And this includes the labor needed to run the equipment during the test, technical staff to observe and evaluate and then as well as others for any training purposes or anything else that you wanna accomplish during the FAT. And really to look at the complexity of equipment will be a key component in the decision for who attends. Then those section below just lays out some responsibility. So we have section for CPG responsibility, OEM responsibility and then shared responsibility. So those are things that really the CPG and OEM should be discussing together. And then the last piece there is important timing for the project. So again, these are just some general things to say, okay, when are you discussing these items and when should you be bringing it up in the project overall? And then the last section on the bottom is leadership guidance. And that leadership guidance is there to help with leadership perspectives to say how do we, what kind of key things we wanna make sure we're not forgetting or overlooking. So from Amway's perspective on staffing, we've definitely learned that we need to have the correct number of people that attend the FATs. It's really from both the OEM and the CPG standpoint. So we typically today send two to five individuals and it depends on the complexity of the equipment and the project. In the past, we've sent anywhere from 10 to 15 and that just becomes a zoo and it's not a good experience. So we try to cut that back quite a bit. So some of the key people that we send will send our maintenance group. We typically try to keep them involved. Their specific roles are gonna look at fit and finish. Any preventive maintenance type things that they can look at and help them potentially modify before that equipment is shipped. They may do some infrared testing to look for any hot spots, any types of areas that may be a concern, again to address before the equipment is shipped. Second group operators and set up personnel. We really love to give these guys some initial exposure to the equipment, potential for advanced training. They can meet up with the OEM personnel as well. And really the best part about these guys is they can be a key ally for starting that equipment up. So you wanna make sure that with these people you're gonna have the same group of individuals that will be responsible for starting up the equipment when it goes into production. Then finally from engineers, we'll look at both project engineers, typically going to the FAT, an electrical engineer if he is not the project engineer, and then occasionally we'll send process engineers as well again depending on which type of equipment we're running. So then we have some others as well. So every once in a while you'll get somebody from sales that'll drop in, R&D, quality, safety personnel. Again, again varied based on the type of equipment. And quality particularly if you're dealing with a very touchy type of product and you need to have somebody there that's responsible to help you make those calls. You wanna have those individuals there so you can say, hey, we've got a successful FAT. We had the right person that can make that qualified judgment and say that that equipment is acceptable or the quality is acceptable. Really main point here is just making sure that everyone is working together. We're all on the same boat, we're heading in the same direction and everyone has a function and it serves a purpose at the FAT. If they're just going along because they want a free dinner or something you probably need to look at that a little bit differently in maybe ask them to do something else to help the team out. Next piece is safety criteria. And really safety is critical. It's probably one of those things that tends to get overlooked a little bit that we found historically. We tend to spend a lot more, pay a lot more attention to safety now. And it's really something that you need to discuss and review before you start executing the FAT. And then probably the main thing under the leadership guidance there is treating that FAT as if we're in operation in your own facility. So you're going to apply your same type of rules and not relax your standards so much just to say, hey, we're going to get through this quick test and then we'll be over with. Then from an AMWI perspective, again, really it can't emphasize enough both OEM and CPG planning conduct a safe FAT. So that requires discussion, communication and you're going to talk about things like, hey, do we have the necessary PPE who's responsible for providing it? So that personal protective equipment, making sure that everybody has exactly what's needed is the guarding on the equipment. Have you addressed pinch points? Are you going to lock out and tag out the equipment as well? That all needs to be discussed and made sure that that's being adhered to. Then just as a quick example, we had an arc flash incident and I'll show you the picture here of the electrical cabinet and everybody's probably seen one of these. As an engineer, as a project engineer in the past, I've spent a lot of time in these cabinets and never really thought a whole lot about it but now in my new role, I think about a little bit differently particularly with some of the changes in the NFPA 70E safety requirements around electrical cabinets.  Well, their technician was in the electrical cabinet and he was doing some final hookups and making some changes.  Well, we look over and he's basically stumbling backwards from the cabinet and you can tell you it stunned and dazed and disoriented and it took him a little while to get, to kind of get sorted out.  So FAT pretest, this is a good one. It's really, it's something that we started probably four or five years ago and it's just a two to five minute pretest to make sure that everything is working satisfactorily before you start executing a longer, longer 15 to 30 minute plus FAT run. And really what you're looking for here is just to demonstrate that equipment is ready and we'll meet the agreed upon criteria between the OEM and the CPG. So there's definitely some communication that is required at this piece. And then from a timing standpoint, we look at two to three weeks before the FAT is ideal and especially with a highly complicated piece of equipment or if you're doing something simple, you can literally do it just before your FAT run. So on the pretest, the main thing for Amway, it's just a key step to help ensure that the equipment is successful. Again, really emphasizing the before committing the time and money for our teams to execute the FAT. We all have stories where we show up and things aren't quite what we planned and we have found that this has been one of the key tools to help make sure that we're all aligned. And when we have these FATs, it's almost a matter of just checking the box and getting through it much easier. So one of the main things we look at, quality, dense, scuff, scratches, jams, et cetera. That's probably what we find as the biggest issues to make sure that we're in alignment with the OEM and then probably the other biggest issue is really rate. So if we spec a machine and we want it to run at 100 units per minute, is it doing that smoothly? Is it on the edge where you're like, yeah, it's kind of at 100, but it's not really there. And then you have the other situations where, yeah, I'm running at 100, but I'm stopping every 15 to 30 seconds due to a jam or some other type of fault error. And those are the types of things that you look at and you see at those points and you say, look, we need to fix this and then document any of the actions necessary to fix these items before we start that actual FAT. So what we found helpful here is really we got the basic things between photos and video. And what we've started incorporating over the last two to three years is really the use of FaceTime and Skype. Everybody's got a smartphone these days and telling you it's a great tool. It comes in handy where we can sit back here in our offices, talk to the OEM, talk to the technicians, have them go out on the floor and show us exactly what the changes that were made, how the equipment's running. You can obviously converse back and forth so there's a good dialogue going on while that's happening. So we found that that's just been a great tool for us to help establish that the equipment is ready and any changes have been taken care of and addressed. And then the last piece on the FAT pretest is really you want to kind of assess your environment. This is a picture of an FAT that we completed earlier this year. You can see there's a lot of nice light, a lot of space to work around. It's generally a pretty safe environment. You got to keep in mind too that it's not a production environment. There's people working and things going on, but just trying to be reasonable with what should be going on and making sure that you discuss and allocate enough space, time, environment is acceptable before completing that FAT, all right? Then the last piece I'm gonna talk about is the FAT performance. And really the main thing we're looking here is that our key attributes that we're going to test. And you're looking at things like your rates, your feeds, pork values, throughput, quality, et cetera. Those things really need to be defined at this point. And then part of the other thing that comes up on this as well is there can be some difficulties testing at full speeds depending on what type of equipment you're doing. If you're just doing one single piece of equipment and you don't have a lot of integration around it, you may need to work around being able to do consecutive batch runs versus continuous runs. So those types of things need to be worked out and discussed as part of the protocol. For FAT performance, again, from Manway's perspective, communication really starts during the RFP process, can't emphasize that enough. You wanna bring that forward and say, hey, we talked about this with the OEM and you agreed upon those base requirements that for the equipment you're looking to install. And then want that to lead to the mutual development of the FAT protocol. And really again, that goes back to clearly defining those key process indicators and agreeing to them and then having well-defined criteria agreed to by necessary individuals. And to bring up the necessary individual space because sometimes everybody's got a good purpose in the team but there can be cases where people are influencing or trying to change decisions and you really wanna make sure you've got that key individual. That's gonna make the call on a quality requirement or a specific component look or whatever type of attribute you're trying to impact. Then the last point on the protocol is really any significant changes. You should be discussing those, agreeing on those and documenting as the project progresses with your OEM. And the overall goal is really just say, hey, we don't have any surprises when that FAT comes up. It's going to be something where everybody on the team is clearly happy with the success and the performance. And again, just emphasizing no surprises. So nice happy team with their little, I got one more click there, little team coming up and everybody's nice and happy right on the team meter. So in summary, look at using the OPEX protocol and checklist, it's available and it'll help you standardize the FAT executions for your organization and really do a better job on getting those completed. And then really using the tools will help you execute a successful FAT for both the CPG and the OEM. And then probably the bottom line is just saying those successful FATs might lead to better installations, qualifications and production startup, which means success for everybody on that project team. So thank you. And now I'd like to turn it over to John Uber from Metler Toledo. Thanks John. This is John Uber from Metler Toledo. My role as product management leader and also I carry another role as product safety and compliance leader for our new facility in Tampa, Florida. So when we first started pulling this presentation together the two outlines for the two presenters were remarkably similar and that was actually for a good reason. The goals of the two parties are essentially the same, just a little bit different points of view. My side of the presentation is going to reinforce a good deal of what Mr. Giles just stated. But one thing that is consistent between the CPG and the OEM, the more thorough the preparation, the more successful the outcome of the FAT. As an example, at the bottom of this, there's a bullet and it gets to the point of the URS or RFPs. And that is you'll find a lot of times that a URS will be responded to with the we comply statement several hundred times. And what we found is it's a much more effective practice that if you explain how you comply, you end up with a lot less indecision and a lot less conflict when you get to the FAT. So that's just a practice of diligence and we'll get to that topic in a moment. As said, the objectives are really the same. On the OEM side, we want to demonstrate how our product is ready to install, integrate and start your production process. You want answers to all of your questions. We need to have those answers ready at the time of the FAT. You want the machine produced on time and that's probably the number one complaint we see across the industry is late equipment on FATs. We need to ship it on time. That's actually a business activity for us. So it's critical for us in terms of maintaining our business. As stated earlier, the keys communication. At the start, at the end, all the way throughout the project. One of the most important steps we took with our FAT process and it is a process is to allocate resources to manage and execute FATs. We consider our order managers as spokes, SPOCs, single points of contact with our customers. And our experience is if there's one spoke on the OEM side and one spoke on the CPG side, the results are always more favorable. Just as Amway needs to organize its team, that literally don't need to assemble a team on the OEM side. You need commercial people to answer the billions shipping questions. You need the SMEs that are there for design questions. You also need SMEs for machine safety, connectivity, integration as a whole. And what's real important for our facility and our product is food safety. These people are used throughout the order process, but are key contributors during an FAT. The communication, the bottom line, communication needs to be both ways. You take a look at that last bullet. And really this is again to reinforce what Mr. Giles said earlier. Up or right, the goal, no surprises. And both parties need to be realistic in their expectations. The OEM should no more expect that the user has already supplied test material for an unlaunched product. Then the CPG should expect that the OEM will be able to fully replicate all the conditions the user will see in full production. Dedicated staff for FATs is probably the biggest factor for success and a luxury we have with our organization. After people comes process, you should really as an OEM establish your own internal process for conducting FATs in your building, but make your process so they can react to your customer's FAT requirements. Ultimately, and this is part of what Mr. Giles said also, you need to reconcile your process with a customer's RFP document or FAT document. And ultimately, the order documents will drive the FAT and determine its success. Another point, don't just send emails. An email to arrange a time followed by a person-to-person discussion is probably the best approach. We all tend to be a little bit, maybe a little bit angrier, maybe that's just me, in text when we're talking to someone. Pick up the phone, range your Webex, use as many media as possible to communicate and the other things that were mentioned before in our great tools, anything visual. Throughout the order process, the FAT leaders should be checking and testing everything. Check engineering progress, check assembly progress, check qualification, check the pre-test with the FAT technicians, and also back with the user. You can buy yourself a lot more time internally if you work up front to close open issues externally. And when there is a change in planning, communicate, reconfirm to all the affected parties. In the last stages before the FAT event, make sure your location, machine, and personnel are ready. And like I said, we've got a luxury down here of our new facility because we have dedicated FAT rooms, we have dedicated storage areas, we have dedicated personnel for FATs, FAT technicians, and also order managers that carry it through. Make sure the test product is where you thought it was and in the right conditions. Nothing disappoints somebody more than seeing an empty box of test products when they arrive for an FAT. When your customers arrive, make sure they're well accommodated and then address safety.  Go through simple things like you would for any external meeting. If there's an emergency, how do they get out of the building? Where should they go? Where should they regroup? So you know where to verify that they are out of the building and nobody's going into the building looking for somebody that's unaccounted for it. If there are weather risks in your area and these kind of happen in Tampa, where do you go for shelter? Are there assigned tornado shelters such as we have here? And another little bit of an esoteric thing is an alligator happens to come across your parking lot. What is the correct local etiquette for making sure that you don't conflict with that beast? Make sure they can interact with you, with their colleagues, both on-site and remote. And if you take a look at the middle sections, you'll see a couple of tables with chairs. We have locations set up for meetings between us and the customer and an area set off to the side also where they can just work within themselves so that they can discuss things that they might not want us to take part in that discussion. Is there adequate phone and adequate internet capability? On machinery safety, you should already have your machine's risk assessment, but take the time to cover the key points of that document even if you're not asked. This is both for their safety and for your protection. What are the guarded hazards? What are the residual risks? What hazards arrived through integration and this is an area where it is becoming a greater area of awareness for the industry as a whole. We are presently preparing a protocol for customer safety during customer visits and at the best time before there's any incident. And the best part of this is this was requested by our FAP and test personnel. It was not driven by safety management. It was not driven by upper management. It was clearly driven by the people who were doing the work. You do need to spend more time on safe and effective integration. The latest anti-standard B-155 issued in 2016 provides really good guidance on this topic. This is often an overlooked area and you can be of great help if you're prepared. So you should be identifying those areas where integration is a concern and we show these on the next slide. On safe integration, we've actually written a process to address the topic. We break it into five areas of integration activity. We've actually had to do this not just with machines we're tying into customers facility but also with machines, our own machines that interact with each other on an FAT. So for instance, we recently had an FAT where we had a checkware or a metal detector and x-ray all in one line. So it became an in-house integration safety exercise for ourselves. But mechanical, electrical signals of communications, safeguards and safety circuits, those are the five buckets we look at as far as safe integration key points. For each of these, the interfaces need to be evaluated and should be reviewed between the supplier and the user during the FAT. If the machine at the FAT has in-feed devices, the integration at the FAT can actually be a great learning tool for the user's integration activity. You should also be prepared to review some of the non-machine deliverables. How do you demonstrate connectivity products such as field bus or OPC communications actually communicate? Are you ready to demonstrate how your product complies with regulatory requirements? That could be radiation safety, that could be OSHA, that could be food safety. Do you have a ready plan for product support? What do you do as far as service and spares? What documentation is provided? And then what is additionally available? We see a tremendous upturn in the amount of requested special documentation that is tailored to fit into our customer's documentation process instead of just our own. And the last part is, where do you get a playbook for all this material? Well, there's all this stuff written down and magically, you don't necessarily need to buy a Metla Toledo machine in order to get this information, although we'd encourage it. The playbook is free, supplied by OpFax as a courtesy to this industry. By the way, we also assess our FAT performance. Each customer is asked to provide feedback on their FAT experience and freelance on what went well, what did not. So at this point, Jim, back to you. Thank you so much, gentlemen, for the insight. And we do have some questions coming in. This first one, I believe, is for John Giles. How do you control the activities during the execution of the FAT and keep things from getting off track? Thanks, Jim. For us, that's a, it can be a tough one. We've worked that out in the past by really going back to the same type of concept that John Ubre mentioned with having that SPOC or that SPOC. So typically our project engineer and the guy who's leading the project and is at the FAT is going to take command, if you will, from the CPG perspective during that FAT. And really it is a way to control that the activities and coordination are going along per the plan. So if you have other people there and they're asking questions and they're doing things, they can tend to, and it's all with good intention, but they may end up derailing or sidetracking some of the main things that you're focusing on to execute that FAT. So having that one single point of contact, that one person that says, hey, I'm in control of what's going on here, if we're going to change direction or change paths, that needs to come back through me and I'll help make that call. And to John's point, we found that when the OEMs do the same thing, it meshes very well together. It reduces a lot of the confusion and helps overall with the FAT execution. That is that single person of contact you had come up with, yes? Yes. Yeah, very good. So for Mr. Hoover, if both the user and the supplier have FAT protocols, which one do you use? I think you mentioned about having to basically reconcile whatever you set up with, with every CPG who comes in. So basically yours has got to be super flexible because you're custom tailoring every time, no? Well, it's flexible and it's not whether you use one or the other. You need to use both. Both the users, the users RRS is really the driver for the FAT activity.  And they're the customer. They're the ones that are paying for this. The OEM's FAT protocol provides consistency in preparation for the FAT from one customer to the next. And it's our internal standard for preparation. The other point is because we have more experience with our product and capabilities, we can identify areas of design that should be tested that the user might not see with an FAT protocol for general machinery. I would not pretend to write an FAT protocol for a filler because I'm not familiar with that machinery. But the customers, it should take advantage of the OEM's expertise and sort of craft their protocol to the particular machine types that they're buying. Very good. Back to Mr. Giles from Amway. How do you determine the number of people who get to attend an FAT? And how do you say no or reject the people who really want to attend it basically? Yeah, that's a good question. I think overall, it really goes back to the basics and making sure that the people that attend, do they have a function and are they going to serve a purpose? And overall, you have to have something for them to do that's meaningful where they're going to contribute. So it's generally an evaluation that you're gonna make internally. And again, it's gonna vary a lot based on the pieces of equipment that you're dealing with. So if you're doing something really simple and you say, yeah, we're doing a unit coder. We have a lot of these around. There's a lot of experience with them. That may be something where you only send one or two people and there's not a lot of need to have somebody else come. So it's pretty easy to say, hey, look, this is simple. We can do it without you and sorry, right? So maybe just be blunt with it. A more complex piece of equipment, again, it's really that same fundamentals, making sure they have a function and serve a purpose. We'll tend to expand that a little bit and allow additional people to come based on their area of expertise. And then probably the easiest way to say no is to say, look, we don't have this budgeted. Our plan was to send three people or four people and your number six or five or whatever happens to be and we don't have that in the budget to be able to cover for that. So hopefully that answers that question. Yeah, and that's just my question. Forgive me for being naive, but are you paying to send your team to see your PCB equipment there or can that be negotiation industry standard? Is it built into the cost of the machine or budgeted? How? Typically we budget for that travel within our project. I'm not aware of any OEMs picking up those costs. I don't believe that's a standard at all in the industry. All right, very good. John Uver, what's the most difficult part of an FAT for the OEM? Well, ultimately you're gonna come across this occasion where things might not go exactly as the way that you thought they would. Things don't go right and they won't always. 99% of those situations when the problem comes up, supplier and the user can resolve to a solution relatively quickly. And that's where your SPOCs really come in handy. It is a bit uncomfortable for each. And generally what you find out is that it wasn't one party that was fully at fault. It was a matter of it was something they missed mutually. But with good process work on each side and diligence and practice, conflicts are generally eliminated before you get to the FAT. Very good. Well gentlemen, it seems like we're running out of time now. So we just want to wrap this up. And Steve Schlegel, could you tell us where we get this OpEx FAT work product? Sure, thanks, Jim. Yeah, it's at the opexleadershipnetwork.org website. And we encourage everyone to visit. And again, a free download for the work products. And I do want to thank everybody for attending today and really appreciate it.


My experience in high school sports like you just kind of focus on the next game or you focus on the next race You're just trying to become better as an individual But I watch a lot of NBA too. So when I'm watching the players I'm thinking like, you know They're doing the best job that they can but they're not seeing the whole floor. They're not seeing the strategic perspective They're not looking at it like a coach I don't know that I could have convinced me five years ago that this was a good opportunity for me I was so focused on, you know, hear all the milestones for being a better acquisitions officer like I have to go to this training I have to get into this program after go to this assignment You know, I have to work in this program office I didn't really see squadron officer school as something that was on my radar So I had no idea what to expect but the last three years Have been a great journey for me in terms of personal and professional development I was able to find the best version of myself And I feel really confident that I can take a lot of the stuff that I learned here a lot of the things that I got to experience and Become a better officer and bring that back to my career field. That's our university


Steven Schwartz in the FitLinks booth and he's got something really odd to show me here. This is called the AMP Strip. It's a 24 by 7 heart rate activity tracker. Okay, now those are a dime a dozen for your wrist and for your elbow and all that kind. Where does this one go? So this goes on to your torso. It connects with a adhesive strip which you place on the back of the device and you can wear it for three to five, three to seven days on your body. For the audio listeners, he's holding something that looks like the size and shape of a bandaid but it's actually got, it's black and yellow and got an oval cut out of the middle of it. Right. So this has got all the electronics in it and it will include an adhesive strip that you pull off after seven days of wear. So you can wear it while you're swimming, you can wear it while you're sleeping as well. Oh, so you can actually get activity tracking when you're swimming. So activity tracking and heart rate monitoring, primarily geared towards competitive athletes. Okay, so what does it measure other than heart rate? So heart rate, skin temperature and posture. So that's how we get sleep. So with posture we know that you're lying down and you can track different levels of sleep cycle based on your skin temperature. So what kind of activities though? So any activity because it tracks heart. Is it, I have step count? Yes, it does step count. That's what I'm asking. What other metrics? So we make another product called the Pebble, which is an activity tracker that you can put in on your shoe and on your belt and so all the technology from that product is in this as well. Well, that's really, really interesting and I see you've got an Indiegogo campaign that's at 96% funded right now. Yeah, we're pretty excited about that. We launched that on Tuesday of last week. Wow. We raised almost $50,000. Nice. Nice. So when would you hope to get something like this out? So the beta of this and that's primarily why we did the Indiegogo campaign was to get a group of beta testers who could help us tell us what's the best way to get the product to market. We haven't traditionally been a consumer company. So this is our first foray into the consumer market and we really want to get it right. That's really, really interesting. I think that might be somewhere you're not going to lose it or forget it, right? I don't think so. Hopefully not. Yeah, we're a Fitbit, but everybody who's ever had a Fitbit has lost a Fitbit too. So some of the offer testers have found that once they've put it on, they don't even know it's there. Very, very interesting. Well, thank you very much and how can people learn more about your product? So if they go to Ampstrip.com, they'll see lots of information about the product. There's also a link to the Indiegogo campaign from Ampstrip.com. And how do you spell that? A-M-P-S-T-R-I-P. Great. Thank you very much, Stephen. Great. Thanks so much.