Name: Oshkosh Defense Modernization Program Using JD Edwards Digital Technology Platform
Uploaded: 2025-03-13T19:40:19.648Z
Duration: 57 min 8 s
Description: Oshkosh Defense Modernization Program Using JD Edwards Digital Technology Platform

Transcript for "Oshkosh Defense Modernization Program Using JD Edwards Digital Technology Platform": Welcome, everyone, and thank you for attending today's webinar, Osh Oshkosh Defense Modernization Program Using JD Edwards digital technology platform. Before we begin, I wanted to cover a few housekeeping items. If you have technical or content related questions during the presentation, please use the q and a window, and we will address them. Closed captioning is available by hovering over the stage area and clicking the CC button at the bottom of the screen. To learn more about today's presenters, you can select the speakers tab in the upper left hand corner. This presentation is being recorded, and all registrants will receive a link to the recording post webinar. And don't forget to visit our additional resources in the resource list. We encourage you to download any resources or links you might find useful. And now I'm pleased to introduce today's moderator, Jay Leis, who serves as Argano senior director of industry strategy. Jay is certified in both Oracle Cloud project management and general project management. With his expertise, Jay leads business transformation and ensures sustained success by implementing and optimizing technology solutions that enhance operational efficiencies and align with strategic business goals. Jay, you may now begin. Carrie, I that very much. Hi, everyone. Thank you for joining us today. We've got an exciting session, and, I'll go ahead and share my, slide here. And can you can that, can you see that? Make sure it's presenting correctly. Alright. Okay. So great. Very excited to be here. Wanted to just mention for those that may not be familiar with the Argano, we were formerly CSS International, and, we've been around for about twenty twenty five years. And in, late in 2021, we joined Argano. And so we are one in the same. It's the same team, same people, same leadership. And, so we are now part of Oracle and, the Oracle business unit, and we have deep expertise in manufacturing, life sciences, engineering, construction, home building, wholesale distribution, and much more. And so we are very proud to be a part of Argano now. We have had a partnership with Oracle for over twenty five years. As CSS, we were exclusively Oracle, and now we have an entire business unit devoted to Oracle services. And so, we are really proud of that partnership, platinum level partnership, I believe. And, we have been doing very good work. You see that net promoter score there is 79. Basically, if you're not familiar with that scale, anything above 39 is considered excellent. So we're, well rated, with our customers and with Oracle. We've won over 55 awards for excellence in the Oracle ecosystem, from various types, and we'll talk about one of those in a moment. And, now that we're part of Argano, we have significantly greater capabilities than what we had as CSS. We now have over 800 practitioners. We've done over a thousand, implementations and are are growing our list of Fortune 500, companies that we've worked with. So down there at the bottom, you see some of the services that we can provide, strategy and consulting, implementation and integration, road map planning, cloud integration and architecture, change management, organizational change management. Managed services and support is a big part of our ongoing, operations. And, also, we have many assessments and tools for those who might be cloud curious and interested in moving from JD Edwards to the cloud. So you can check out more at oracle.Argano.com. So with that, we'll head on over to the next slide. And, this is something that we're very proud of. We did just win the North America applications innovation award, from Oracle, so we're very proud of that. That's one of the 55 plus awards that we've gotten. But the the really interesting thing about that is, you know, it's really validating that we are focused on solving our our our clients' challenges using Oracle solutions. So, it was granted because we developed and delivered a a pioneering solution by partnering with Oracle. So, enough about Argano, and, I would like to introduce my friend and, our our cohost here, Michael Hovanec. Michael was, is the, director of global procurement and supply chain at Oshkosh Defense. And, having had the privilege of working with him on a daily basis for the last five years, I have tremendous respect for Michael, and, he's a hands on business leader, very, good at simplifying complex matters, very good at negotiating with the business and IT and all the various stakeholders that are part of such a transformational ERP system. So with that, I'll turn it over to Michael, and we'll move on to the next slide. Michael? Alright. Well, good afternoon. Thank you. Very excited to be here, and thank you, Jay, for the kind words and the introduction. I just wanna make sure to do a sound check real quick. Okay? Can you hear me okay? Hi. Yeah. I can hear you fine. Alright. Great. Okay. Well, thank you. What I'd like to do, is give a provide a background on, Oshkosh, give a little overview of the corporation, then get into a bit of the defense segment that I'm part of. And then we'd like to share our journey and, what we were able to accomplish for the business and for our team members and for our customers. And then after that, we'll have, I believe a question and answer session. So, we'll give you probably about a half hour or so presentation and overview, and then we'll open it up and try and leave as much time as we can for questions. So Oshkosh Corporation, you know, first of all, whenever I people ask me where I work, I say Oshkosh and they think it's the the clothing company, but it's not. This is Oshkosh Corporation. We're a global industrial technology company focused on innovating or, innovating and and building purpose, built vehicles and equipment for our customers. The bottom line is that we provide solutions and and that's how we, we look at our future is as helping our customers be successful. So our purpose, is really to make those, lives better, and to build vehicles and protect communities, across the world. And we do that with our core values. We have a very strong culture of putting people first, of, persevering, and doing the right thing. And then altogether, you know, we think we're better, when we work as one team supporting, our stakeholders, and our customers. We do have a portfolio of various businesses. We're broken out into three segments. We have a vocational segment, an access segment, and a defense segment, and then a corporate. All of the brands that you see on the screen are are part of or under one of those segments. You probably have heard more of our brand names than you probably have of the Oshkosh Corporation. JLG is a very large segment of access and platform equipment. You probably heard of Pierce, which is custom fire apparatus. McNealys is our refuge, collection vehicles. We've recently purchased Oshkosh Airtech, which makes, world class aviation ground support and, gate equipment. And then there's, other brands as well that probably weren't as well known but very important to us, Frontline, IMT, Gerdan. Alright. Somehow I got disconnected. Yeah. Sorry. I don't know what happened. Where did I leave off? Did I, I think Yeah. We we heard you finish the last slide, so we're on the next slide. Yeah. Sorry, for the interruption. Alright. This slide, gives a bit, overview of those different segments and then also some statistics, on the company. Our stock ticker is OSK. If you'd like to go check it out, we do have a website that's out there as well, Oshkosh corporation. And you can go over more detail on all the different brands and our locations. Our revenue was about 10,760,000,000.00 And our guidance for next year is very similar. But all of that is in public domain documents in the investor section. I mentioned we had those three different segments. So the defense segment primarily is tactical wheeled vehicles. We're the global leader in that space. And then we also have the USPS next generation delivery vehicle that's out of our Spartanburg facility in South Carolina. We do have a very nice backlog of vehicles there. The the orders call for 50,000 with the ability to go up to 165,000 on extensions, and we're just starting up full rate production now, and we expect to be in full rate production by the, by the end of the year. Vocational segment has a couple of those other brands that we mentioned are Pierce Fire and Emergency Equipment, McNelis, Aerotech, and then our access segment has JLG Jourdan. And the reason that I wanted to mention this is to give you some flavor for the type of products that we manufacture. These are all very large. Some of them are custom built. Some of them are for stock. We have a very large spectrum of the type of vehicles that we produce and the manufacturing processes. So when it comes to an ERP system, it has to be able to handle, quite a bit of that flexibility, that we do have, make to order, we have make to stock, we have multiple facilities, and we need an ERP system that can leverage all of that and help us run our business. Next slide. All right. A little bit about Oshkosh Defense. I think I touched on some of these points, but, Oshkosh Defense is the leader in the tactical wheeled vehicle space. We have a family of vehicles that provide mobility technology solutions for the industry. And, we've produced, over 190,000 combat, ready vehicles over the past hundred years. So we've got a lot of history, a lot of experience working with our customer, a lot of experience, supporting the warfighter, and we're very proud of, of the products that we make. The entire team really has a passion, for providing, vehicles that, that support our warfighter. Next slide, please. Alright. Last slide on the background and then we'll get into some of the project, but I wanted to put this out here because it really hits home. You know, sometimes we get so lost in our jobs and we get siloed into what we're doing and it becomes work. But when you really step back and look at this, you know, these are some testimonials from some of our customers, from our war fighters. And there's nothing better than hearing from a father or from a mother, that our product literally saved their loved ones' lives and that they were able to complete their mission, and come back safe to their family. So we have a passion around this. We really support this, and, there's nothing better than getting these types of testimonials on our products. So all the work, all the long hours, all the sacrifices, you know, the team makes, hearing this really makes it worth it. So we have a passion around that. And we have a passion around, obviously, this ERP system that helps support us to make these products. So next slide, and we'll get into some of the, particulars on our project. You know, how we were structured, how we went about solutioning, and how we're able to get some success for the business. This is our story. It's kind of a one page summary of, really the history and and where we wanted to go. So it's a a access. On the left hand side is capabilities and efficiencies of the ERP system, and then on the bottom of that scale is a spectrum or a timeline of of going live. We've had JD Edwards platform running our aftermarket business and what we call our whole goods business for the past twenty plus years. A great platform. We've we've, really optimized it, but we've recognized that there's only so much you can do with this platform. It is an aging platform. It began, to peak out, years ago, and we decided, hey. We needed to get on to the next platform that can allow us to, scale, can allow us to grow, and and can allow us to continue our optimization journey. So our strategy was to, migrate over to the business, the entire business, over to, defense business over to the enterprise one platform. And our strategy was to get baseline functionality. It's such a big, large system, and you'll see with, with, over a thousand modified objects that we wanted to get the technology and we wanted to get the platform in. We wanted to get people used to this new architecture, and then we would continue on with our improvement journey. So that's the value of this. We wanted to put both we had an aftermarket and we had a whole goods business. We're putting them in one ecosystem. We wanted to standardize processes as much as we could. We wanted to share data. We wanted to share a common chart of accounts with not only us, but our corporate team, get code current and the ability to stay code current and leverage our knowledge of the JD Edwards, JD Edwards ecosystem and then position ourselves for scalable growth. So that's why we selected JD, EnterpriseOne and then also our partners, Argano, because they have so much experience in this space and our cultures and, the work teams really fit together nicely and I'll talk about that here in a bit. So next slide, please. Alright. Case for change. You know, overall, I mentioned this briefly up above, but, you know, simplification. We we've had a legacy system for many, many years. We've added to it. We've optimized it, and, people come and go. And, and sometimes because our IT team could move quick enough, we had, shadow IT going on and people create additional applications. So we had a lot of this offline and out of the ERP system. So we wanted to bring that back in. We wanted to simplify processes. We wanted to maximize, the new technology platform and then allow us to grow, as the strategy said above. So we had, three pillars of simplify, innovate, and grow strategy. Next slide. Alright. Project goals, pretty simple, pretty common, I would think, with most projects is that, obviously, we wanted to migrate onto the platform. So we had the nine point two point five, instance that we were, that we were, leveraging and and moving to from our JD Edwards World seven point three and eight point one. As I mentioned, we had two different instances of World, one for aftermarket and one for whole goods production. We wanted to stay within our project budget and schedule, which we did, and then we wanted to accomplish all of our milestone goals, within the project planning. And we partnered with Argano. We brought them in and I'll share with you Aaron a little bit how we broke it up into the 11 different planning groups. And we had Argano partnered with us at every phase, project management phase, leadership phase, and then with the actual execution piece of each work stream. So we'll talk about that here in a bit. Next slide, please. Alright. A little bit of customization history kind of, you know, gives you some idea of the of the scope and and what we had in front of us. You know, we launched, JD Edwards World back in the late nineties. And and what this chart shows is the total number of, custom objects on the left hand side and then time starting from nineteen ninety seven all the way up to, twenty eighteen. And the blue light blue shaded area is the total cumulative number of custom objects or modifications that we made to the ERP system. And then the blue line shows how many per year that we had done. So obviously when we launched, the world in in 1998, we did have over a thousand custom objects. We wanted to optimize it and, support, for our efficiencies and manufacturing processes. So we had an implementation project, as everyone would expect, about a two year project and we implemented. And then after that, we optimized annually. We had about a hundred, custom objects that we modified each year for various reasons, and that's what's in the gray box. We had customer requirements as we get new contracts, as we're fortunate enough to win new contracts from our customer. There are performance clauses, and, we wanted to optimize the system to support that operational efficiencies for obvious reasons, regulation and compliance, system performance in general. And then we, I believe we have about 38 interfaces, custom or third party interfaces into the ERP system. So as we needed to, to interface those, we had, you know, some, some additional objects and work we had to do there. So that's our kind of our optimization journey over the year. Next slide. All right. Previous slide we showed, you know, those 3,500 cumulative custom objects at the time we started this project, approximately five years ago, we had 17 a little over 1,700 active custom objects. We broke that out into 250 different application groups. We had 15 different what we call edge systems that interfaced into the ERP. And, to make this more manageable and to make sure that we had responsibility for for all of these different applications and for all of the business processes tied to them. We wanted to break it down into what, Oshkosh calls the 11 planning groups or work streams. And we leveraged off of the knowledge and the and the way the modules are set up in JD Edwards. So we kind of pivoted. We started with the six, of the planning groups that that are within JD Edwards, and then we stratified those a little bit more, to make it more knowledgeable so that the people from, Oshkosh would know what it what it means. So next slide. Yeah. So, typically, there's the six JE planning groups, design to market, quote to delivery, procure to receipt, planned inventory, record to report, and then call to resolution. That that didn't really resonate with the Oshkosh team. We don't go through ERP upgrades, quite often. So, that term didn't really mean as much as it did on the 11 that we had listed below. The the team knows what bill of materials are and configurator. There's a whole sales order, process, and they know that. They know procurement and MRP. And then our planned inventory, we broke out into the inventories. We have specific work orders, a very complex work order process. We have armor traceability, production management, and quality, all of us in that kind of planned inventory space, record to report, obviously finance, and then call to resolution service. So we broke them out so that we had accountability and leadership, at each group. And what we did is pair an Argano functional consultant with each of those 11 work streams. We did have some some, doubling up in some of the areas. I believe, Jay, we had, six functional consultants that supported, on this full time, and we split them up amongst those, different planning groups. And it really worked well because we had ownership. It was kind of a hub and a spoke. We really paired up what we call it a business partner lead. In each of those work streams, we pulled some, someone, a knowledge based person out of the business to lead each of those planning groups, and we partnered up with an arg Argano expert, and those were very high performing teams. We then paired up business analyst, we paired up an SA, a systems analyst, and, those were what we call, you know, solutioning teams. And, they control the destiny in each one of those areas. We created an overall project plan. We created standardized tools, that the team used, and then those, work streams would go about solutioning to the cadence and using the tools that we had. So it was really effective. Jay, I don't I don't know if you wanna add anything, but this was kind of the secret sauce on, you know, making sure that, we had accountability at all levels, which was which was wonderful. Yeah. And I'll say that was really important as well because some of the customizations that Oshkosh had implemented over that, you know, twenty plus year history, you know, some of them, we didn't have great documentation for, if any documentation. Sometimes, you know, the people who did that development or who requested that functionality in the first place were no longer with the organization, had retired and move on. So there's a knowledge gap there, and so it really took this entire kind of group of people to determine why is this customization in the system today, and do we need to move it forward given the new functionality that's available in EnterpriseOne. So it really was a team effort. And, by by grouping them like this, we really had a comprehensive view of that functional area, and it I think it worked out extremely well. Mhmm. Yes. Yeah. I think we had one more area in there that, for inventory. I think we had a materials, that we actually split out as well. So inventory, was kind of a later on, I think we added that as a separate sub team. But, yes, I agree, with your comments. And we'll talk about that a bit more. We have, I think, one more slide on how we went about solution methodology. So yeah. Thank you for the comments. Yeah. Next slide. Mhmm. Yeah. So as we spoke about this, previously here, was we we we call this our solution methodology. So what we wanted to do, as Jay mentioned, is first understand that functionality. What is the business process? What what do we really need the ERP system to support, in terms of a business process? What's there now? So we did that analysis of the as is and the to be, to determine really, you know, what is that customization doing. And as Jay mentioned, you know, some of these things were written fifteen years ago, and and they were written in RPG, which really is a very common language. So so we had to sometimes literally read through that code to see what it was doing and then, evaluate the solution options with the newer technology, with EnterpriseOne, with orchestrations, with DaaS, with the UXOne suite. You know, maybe there's a better way of doing this. So So what we wanted to do is give the business, on that very first chart you saw was the same level, of of, solutioning, of capability. We want them to be able to run the business the way they ran the business. If there's a way that we could do it better, we leverage that better tool. So, you know, we just didn't, blindly rewrite, a lot of these customizations. We wanted to understand functionality, what we were trying to solve for, and then see if there's a more efficient, more more effective way of of solutioning. All with the you know, that last point is harmonizing, you know, aftermarket and whole goods. We wanted to create a foundation that we can build upon so it's scalable for the future. And as I mentioned, leveraging that, UX one tool and then enabling, citizen developers, which we'll talk here a bit. I think everybody has this shadow IT that's out there in the business and and we'll talk a little bit about how we address that challenge. Thank you. Next slide. Citizen development, we call them citizen developers. I think most organizations have this where you have, some very skilled team members. Peep there's there's always opportunities in business, always opportunities to do things a little more efficiently, and and we had that in the business. As you can imagine, we have, I think, over close to 2,000 team members in the defense segment, multiple multiple business processes, and, you know, the speed to solution, new opportunities and challenges, sometimes the IT department just couldn't get it done. So we had these developers out there that created, some of their own solutioning. They would literally go out and chat with third party software providers. Sometimes they would develop their own internal, business processes and flows leveraging, you know, a VB scripts and macros and Excel. They had access, they had ODBC, connections. And, so we had quite a bit, hundreds of of well, actually thousands of reports that were out in the business. So sometimes we just couldn't get to it, and the applications, you know, we needed to be more sophisticated. We had duplications of solutions and then when one of these citizen developers moved on to a different segment, we didn't know how the program was written. Security, was an issue. So, a lot of challenges with that. So next slide. So what we this is a this is just a visual representation of the of the spectrum that we were kind of on. So we started on the left hand side, that past past state, where we really didn't have oversight and as many controls as we'd like. Applications became siloed and focused in that department, and, users, really had, had control. So obviously, there was some resistance when when we went down the JD Edwards EnterpriseOne path because those connections, were no longer, gonna be allowed. So ODBC wasn't allowed. We wanted some tools that for that allowed for, more support of the business, more involvement from the IT team, and we really wanted to structure how we went about this. So we would created what we call it a citizen developer network. We wanted to make this part of our solutioning. So we had, leaders, from each of those work streams that we mentioned. So all those different planning groups had a citizen developer network. So we had people that were the relationship owners, and then we had actual, writers or developers themselves on this team. And we would meet, monthly with them. We took an inventory of all the satellite IT that was out there. We then evaluated it as a team, and, we put some controls around the tools that they were gonna use. And, we really integrated this solutioning process together so that we would all be part of this team. IT would know what they're doing. We would authorize the tools that that they're using, and we would know what they're doing. And that then slowly allowed for the right hand side, which was, you know, adoption and and the ability to continue to mature processes. So we went through this whole spectrum of, people really doing what they wanted to support their business, to pulling them in, having them work together as a team. And this, as I mentioned, was all part of our, solutioning process for the for the ERP project. So next slide, please. Yeah. This shows a little bit more more detail, you know, on those super users and then we, we turned them into citizen developers. So as I mentioned, they had, some of these super users had a direct connection into the JDE database into the ODBC. There were different tools that we use. We had Worldwriter. We had Showcase. We had Excel. And we really wanted to consolidate that into a couple different writing platforms. And so at the end, we ended up with primarily the majority of the reports using ReportsNow DaaS. It has, really nice integration features with JD Edwards, and it also allows, for enhanced security. And then you can, actually publish, an approved report. So we were able to create a whole, structure of reports by department, and those were the managed and authorized and controlled, by those citizen developers. So that when a team wants to run an inventory, they use the approved, DAS report to do that. And as I mentioned, we kinda locked down that ODBC. We trained them. We had training courses, with, ReportsNow team. We had different levels, DAS one zero one, DAS two zero one, DAS three zero one for those that just wanna run reports and for those that want to develop reports and then for those that want to publish reports. And the chart on the right kinda shows the access level of what we wanted to do. We wanted users to be able to, run DAS reports that were created and published. We wanted to give them the knowledge on how to create their own, personal grids. Wanted to give them knowledge on how to create queries. That's one of the benefits, upgrades of, JD Edwards World. I'm sorry, EnterpriseOne overworld is is that you have that flexibility in grids and queries. And then using that UXOne tool suite, the watch list, the springboards, composite pages, you know, developing the Power BI, we really wanted our citizen developers to partner with our VAs, to make sure that we can create that consistently. So we'll have, let's say, a, composite page for a buyer or or a senior buyer or for a financial analyst. And so that's the strategy that we headed down. So it, it gained traction and seemed to work well and, the business is is pleased with the direction that we're heading. So next slide. Alright. So, in summary, I guess, we kinda coined the term DaaS becomes your new best friend. The the strategy was use the tools that we have out there first. Run DaaS or create a DaaS report. That usually handles most of it it if you can't get it out of the DRP system. Now with the enhanced capability of exporting data and exporting grids, you know, it was a lot easier. So use those tools. Then if we need to develop, some additional, UX one tool suites, we would. We can go through orchestrations, watch lists, springboards, as I mentioned. And then this really helped the team. You know, part of what we also did with our training when we deployed this is that we had different sessions of what we called one zero one. We had MRP one zero one. We had, running, inventory reports one zero one. So we had different training sessions. We really wanted the people to learn ERP and how the ERP system works, and the tools that were within the ERP system so that we can mitigate the need to go out and have this citizen developer network, to have these shadow developers and to have these other applications, being brought in that weren't, part of IT. And then be willing to use those tools, be willing to, learn. And, yeah, as I mentioned, we really gained traction with the strategy because now the business, feels that, there's a there's an enhanced level of support that we're listening. We gave them the tools to be successful, and we're supporting those tools. We still allow, that entrepreneurship. We still allow them to go out and optimize and, and support their businesses, but it's within the confines of the tools and the structures that IT is aware of and has, kind of deputized them to use. So, Next slide. I think we get into some of the summary. This is the, I guess, overall project benefits. Some of the things that came out of this that supported the business, we were able to leverage existing infrastructure. So as you know, there's quite a few servers, a lot of hardware, multiple devices, our scanners. We have Thor units. We have different scanners. So we're able to leverage all that because the ecosystem, was similar. So going from a world up to enterprise one, was, a little easier for us. We leverage that in house knowledge. We had quite a few users, obviously, thousands of them that were familiar with JD Edwards, the way the tables are structured, behind the scenes for creating these reports, all consistent. So it really helped the the names of all the different, you know, columns in in the grid, similar. So it was a little easier for us to, train the team on this, transition than going to a completely new ERP system. Argano brought with us, or to us, you know, deep product and industry functionality. Through this engagement, we were able to leverage. As Jay mentioned, we started off with CSS, then the the, merger with, Argano occurred and allowed for enhanced portfolio of knowledge, and processes. So we were able to leverage that in in pretty much a lot of areas. And when we came to a kind of fork in the road, how can we solution for this? It was nice to get, a varying opinions. Less disruption to the business, still JD Edwards. You know, we've grown, into these new modules as, JD Edwards has grown into them. So there's over a 50 different modules. I think we as Oshkosh have over 80 of them that I think we're using throughout the different businesses. So we're leveraging quite a bit of that ecosystem. Support the platforms that we already had. I mentioned that. There were some manufacturing efficiency gains. As I mentioned, more of this went into the system now. So instead of having 2,000 satellite IT reports, we try to put as much into the system as we can. You know, that's the next line. I think we had over 2,000 reports in the business. And what we found out there was quite a bit of duplication, and if we can consolidate reports and just the need, or the the ability to export the data out of JD Edwards eliminated 35% of our reports that we had, because it was easier for the users to just export that grid. So we did a nice job with the consolidation. We have improved reporting compliance because now, as I mentioned, DaaS allows us to lock out that report and to publish a version. And you can publish the version to, users based on their security profile. So that really helped us with our compliance and to make sure that the, people are running the right reports. We did integrate with, Windchill as the PLM platform that we're using. So we, we were able to integrate that, as one of our 38 integrations. It helped us with our quality control inspection process, doing, skip logging and approvals and routings. The workflow was, obviously much better than what was in the world. We were able to tie in some nice optimization with our warehouse, the Thor units that we use, very quick, and we tab enabled some of the screens so that we could jump from, you know, input screen to input screen where you're doing high volume receipts. They didn't need to really navigate through JD Edwards as much as, we wanted to just move right to the screens that that we needed. And then, that first slide kinda put it together where we wanted to launch the same level of of, solutioning to the business and then optimize as we go forward. And, you know, we're gonna leverage that, UX one toolset. And and really, now we're getting into now that we've kinda gone through, our launch, we've gone through our hypercare, we're kind of in this steady state. And so, you know, that's the next, phase of this is to really leverage, that capability of alert, analyze, and act. So, you know, that's the summary. I think it was a wonderful partnership with Argano. They, you know, as I mentioned, Jay and I partnered together, at a leadership level. We had, functional consultants. We brought in data experts. We brought in a resource to help, with cutover planning, we had over 2,000 line cutover plan that was managed. Really every area, the technology side, RSAs, their development team partnered together. It was, you know, just really every every aspect and every function you can think of that we needed support. It really was a partnership and, you know, they supported us, and and I can't say enough about, you know, the relationship. I think they really were one of the keys in our success. They brought a nice portfolio of tools to us that we used, the whole PDP platform we used. And I think that helped with standardizing, these work stream teams that we that we had, that we had mentioned earlier. They use the same tools. They knew the same cadence. We had the same processes, the same statusing, locating all of the requirements, locating the solutioning, locating the project plan, locating the cutover plan. It was really a nice platform. So, very positive experience for us and, glad that, they were a partner in our success. So with that, I mentioned we save us, some time for questioning. So, Jay, anything else to add before we get into the questioning? No. I think that's it. And just maybe one more thing about the tools is that, you know, we we we had a very large team across, you know, multiple geographic areas, multiple sites, around, and having a centralized toolset, with with such a complex project that required so much coordination. You know? If the technology team was needing to do something, then we had to coordinate with all the business teams and, you know, when testing was going to occur, when data conversions were done. And there was input from so many people throughout the way. So having a centralized toolset, I think, really was critical to managing all that. And and as Michael mentioned, our our PDP system project delivery portal platform, sorry. PDP is, really essential to that, and it really enabled us to, you know, develop predecessors. So you can't do z until you do a b c. Right? And assigning each of those tasks to someone and then having that show up on their PDP, status of of what they need to work on next, was really critical to coordinating such a large diverse team across the consulting organization as well as the business organization, as well as the IT and corporate organizations as well. So, there is just a tremendous amount of coordination that had to happen to make this successful, and I think we were able to do that. You know, as Michael mentioned, a a 2,000 line cutover plan is pretty intense. And, there was lots of dependencies and, you know, whole sections of the plan couldn't be completed until a step was done and being able to understand the status of that. You know? They're working on it. It's in progress. You know? Now it's complete. Now we can start with the next status. So I think that was that whole coordination effort, that's just one example of many. We had that same thing around data conversions, around testing, around, development and and, all those types of the ship. I mean, Oshkosh and Michael helped us to, you know, refine and improve those tools over time to now where they're, you know, laser focused on being able to to do those types of things going forward. So we appreciate your partnership on that as well. So alright. Thank you, Michael. That was amazing. Let's flip over to questions and answers. Maybe Carrie, are you on? Guys, thanks to you both for such a great session. Now I'd like to open it up for q and a, and you can put any questions in the Q and A box. Okay. Alright. Let's see if we have any questions here. So, here's one. So, Michael, so, one of the questions is with so many customizations and and changes, how did we prioritize or determine what to do first? Can you talk about that a little? Yeah. Sure. Thank you. Yeah. For the question. So what we did is, try and determine first when we had over, I think over a thousand different requirements and some of those requirements had multiple requirements below them. So, you know, it was a it was a very large, endeavor. And so we you know, how do we do this efficiently? What we came up with is that we wanted to look at the order in which, those customizations or those requirements fit into our product realization flow. So we wanted to take a look and say, hey. We need to really have good data first, so let's do data. We need to understand these customizations. Let's dig into the existing customizations, and then let's look at where they fit in this, product. So if anything tied to sales, we probably wanna do that first. Bill structures, we wanna do that first. Anything with, running MRP, do that. Then we would move to inventory, then we'd move to, finance was, kind of last in quality because you can't inspect the part until you're able to order the part. So we wanted to look at, you know, where that fit in in the product realization cycle, and then the level of effort that was required as well. You know, some of these big and large, analysis we wanted to do first. So it was really the level of the effort and where it fit in the process order. Great. Thank you. And then I'll also say from, you know, from a very tactical perspective, when you have such a large, you know, universe of of things that need to be retrofitted and and recreated, it's an entirely new platform. So you can't take code from RPG and just copy paste into, enterprise one as as most of us know, I'm sure. So we did really have to analyze that, compare it with, you know, the tools that were available. And, you know, we really did have to start with the data. Right? We had to get the tables in place before you can build programs on top of the tables. And in some cases, that meant, you know, harmonizing, data between the various business sec segments and locations and and and that kind of thing. So, you know, having those planning groups and then starting kinda one by one and making sure the data foundation was there and then moving into, you know, the programs on top of it and then the outputs of those programs after that, was really the, you know, very simplistic way to to kinda look at, you know, how do we prioritize. And and we also did go through an effort to prioritize not only what order do things need to go in, you know, like I mentioned tables first, but also within a functional, area, what are the most critical programs? Because not everything can be equal. Right? You can't work on every critical if everything's critical, you know, nothing's critical. So, we really did make an effort to try to create almost a bell curve like, prioritization of the of the requirements that were out there. And it didn't exactly end up in a bell curve in every case, but at least it gave us direction. Right? So that was very helpful. So, Michael, there's a, another question here. It's really a three part question. So the first part is, how did you dedicate people for five plus years? The second part is, how did you keep them engaged and motivated for five years or more? And the third part is, how did you define set success with constant motion, happening all around us? Yes. Let's get into those. Thank you for the question. How do we get people for five years? We started with a steering committee from leadership. The leader of all of the different functional areas were part of the steering committee. And, we knew from the beginning for us to be successful, we wanted this to be a business, system enhancement, not an IT project. So we didn't want just IT resources working on this coming to the business saying, here you go because, you just don't have the level of involvement. So from the beginning, we knew we'd have to pull some people out of the business, and we created a role, on the DT team called business process leads. And we selected knowledge experts out of the business. They didn't know every single process, but they knew, just about of all of the processes and who the specific subject matter expert might have been if it wasn't them. So we pulled, a really good knowledge person out of each of those major work streams. We had eight business process leads representing, those 11 work streams, and they were sort of that hub, in the middle of the entire spoke. So they were the ones that reached out to their peers in the business if they didn't understand or know a process, and and that's how we kinda got subject matter expert engagement. And they knew this was gonna be a long term commitment, you know, anywhere from three to, to five years. We did have some transition on the team. We did have some people, you know, bid on some promotions and move to other areas. No one left the team because they didn't like it, which kind of is a testament to to, Jay's team and and and to the mission of the team. But we did have some people leave for promotion, and we, you know, backfilled with another person from, from the, from the organization. I think the other one was how did you keep them motivated? You know, what what we tried to do was break it down into smaller segments. When you look at a five year project, it's really hard to to maintain momentum. So we really broke it down into having those goals, and and we defined out the project schedule on, how many requirements do we have and how many do we want a solution for this week, or how many do we want a solution for this month. Then we tracked our CRP sprints. We tracked, IST. We knew exactly how many scenarios we wanted to run. We planned when we wanted to run them in general, with the business. And then we would kinda plan versus actual. So it kinda kept the team motivated to know, you know, where we were in terms of, the entire solutioning. So we kept that in front of them. We didn't wanna overwhelm, so we broke it down into smaller chunks. And then the third question was, how did we measure, the success, I think? Yeah. With constant motion, you know Yeah. Ongoing business, special projects, competing initiatives, that kind of thing. Yeah. So, again, we had, and I don't know if, yeah. So I'll touch on this. May not be part of the actual question. But not only did we have the steering committee, which had the majority of the vice presidents from the business in there, but we created something, out of need. We didn't do this initially, but we found about a year or so into this, that it would be really beneficial to get the functional leaders of those areas. Not that the VPs weren't leaders, but we wanted the managers, or the directors that were over these different areas that all of the subject matter experts reported up to. It's one thing to talk to, you know, the vice president of sales or vice president of marketing. Their their focus and their tactical knowledge, of these processes probably isn't as good as as a manager. So we created what we called a decision committee. And, we would talk to the steering committee first, and then we would go to the decision committee, and we would explain, you know, where we are in the project. Why do we need your subject matter experts? What are they gonna be working on? You know, here's a decision. If we got stuck and there were competing interests, purchasing or quality or whatever may have had competing interests. How do we decide? Purchasing once one thing, sales once another thing or quality once another process. Do we inspect parts on the dock or do we pull them put them in inventory and then inspect them after they're received in? So these kind of questions, we would work through our project team. If a project team got stuck, we would then escalate to this decision committee and that's where the name came from. So we started pulling the directors and the managers from the business, tying them into the project, reviewing the milestones, reviewing expectations, and it really made this project a business project, not an IT project. And I think that's why we gained so much traction with the business is they understood where we're at. We had a cadence. We would meet, every two weeks with a steering committee and we'd meet every two weeks with a decision committee and we offset the timing. So every, Friday we met with steering committee, next Friday decision committee, next Friday steering committee, next Friday decision committee, etcetera etcetera. And we did that for pretty much the project and I think it really helped us to gain traction with the business and to keep the team engaged and keep the team together. So Sorry. I was on mute. Great, Michael. Thank you. Maybe, one more question. How how did we go live? Was it one big bang or was there a series of deployments? How did we you wanna talk about how we took this, massive project and brought it live? Yes. Controlled chaos, maybe. That's, I guess, one word. But, as I mentioned, we had this in phases. We we had three, separate go lives. First one was what we called the, TPF, total package fielding. It was about 60 users, and, it was, it was a good learning. So we launched that first, and gained experience, did a reflection afterwards, what went well, didn't go well. And then the next phase was launching our aftermarket business that had about 500 or so users. And then the last phase, the largest was, launching, our whole goods production that had about 18 a little over 1,800 users. So we staggered this over, you know, over multiple years in multiple phases. We did, the total package fielding launch more or less over the weekend. We did aftermarket launch more or less over a weekend during July 4, and then it took us about a week. We took the the week of July 4 to, cut over for our whole goods team. We had a quite quite a lot going on that week. But, yeah, that's how we did it in three in three phases. Mhmm. Yep. And, you know, the the phasing of go lives is, you know, there's pros and cons to that. Right? So on the one hand, you get some quick wins. You, as you mentioned with total package feeling, the smaller one, we dipped our toe into the enterprise one water, so to speak, and got Mhmm. Got, you know, used to that system. And then we brought in aftermarket, and then we brought in whole goods. And, you know, we we had to convert something like 10,000,000,000 records, data records. So that takes time. Even with the most powerful, you know, computers out there, that just purely takes time. And so then there's you know, you gotta extract the data. You gotta back everything up. You have to, validate the data. You know, you wanna do some prechecks before it goes into the live system and merges that data together, and then merging all that data is is quite the feat as well. Not to mention all the process things that have to happen around that. Right? Financials and, you know, inventory reconciliations and all those kinds of things. So it it was, an extended downtime, but it was an oversized project. So, it, it it it was the best solution for the situation. It it minimized some risk by having phase go lives, but it did increase a little complexity instead of converting data into a brand new clean slate environment. We had to merge the data with the system and users, and an operation that was already in flight, right, and already using the production system. So, there's pros and cons to that, but, you know, it it every every customer has their own risk reward profile, and I think we manage it really well here. Mhmm. So Yes. Alright. I think that's it. I'm checking. Maybe, Carrie, you could assist me. I don't see really any other questions from the audience. Is there any? I don't I don't think so. So maybe I'll turn it I'll turn it back over to you, Carrie, to wrap us up. Thank you, Michael. Thank you. I don't see additional questions at this time. This will conclude our q and a session for today. Quick reminder to check out our, sorry, our oil we're featuring an oil dry webinar a webinar with oil dry, on April 22. Be sure to register and check it out. You can look in the chat for more information. Additionally, you can check out our, JD Edwards coverage, content. You can look in the chat for that as well. And we want to thank Michael for presenting today, and we hope you join us for our next event. Thank you so much, everyone. Yeah. Thank you. Appreciate it. Have a good day.