Digitalization CollABorative March 2025 - Meet the Member: Journey to IFS Cloud with Chris Rundell, Covia

IFS Digitalization CollABorative: Tech Talk - Meet the Member - Journey to IFS Cloud w/ Chris Rundell, Covia

Date of Meeting: 13 March 2025 10:00 AM US Eastern Standard Time

Chris Rundell Presentation:  

Slide: Who is Covia

• Without getting too deep into Covia, we're a premier provider of industrial minerals. We're headquartered in Independence, Ohio. We were actually formed through a merger between Fairmount Santrol and Unimin. So I work for Fairmount Santrol, which is based in Ohio. Fairmount was about maybe the number three size company in silica, and Unimin was number one, owned by a European conglomerate and we merged and became Covia back in 2018.
• We service customers in a number of industries with construction class, foundry, sports and recreation. We also had a large business for Frac sand which we just spun off as an energy company. So that was one of the projects I did last year, which was to carve out the energy division and to separate them on their own. So now they're called Iron Oak. We're still working with it very closely. In fact, they're still on a lot of our systems, but we're in the process of separating the technology.
• A lot of our products are sand and clay and were sourced from locations in the US, Canada and Mexico. I think there's 33-34 plants in US and Canada and maybe 10 down in Mexico. In Mexico, you've probably come across the glass that is made from our sand for Corona and Modelo. We do a lot of our favourite beverage importers down there.
• We try to focus on sustainability and on innovative solutions. In fact, we're just opening up a new research and development lab down in North Carolina, just made a big investment in that and that is in the process of opening.
• And I didn't mention ahead of time, my role is in IT, I'm responsible for all the IT projects, particularly the major ones. I managed the demand process for new requirements coming in and then I manage the larger projects for the organisation. So, my background was in IFS and that was my full-time job until recently when they said, hey, let's have you do this elsewhere too. So that's how my role has evolved.

Slide: Covia and IFS

• I mentioned the merger and Unimin had actually implemented Apps 9 in 2015 or 2016 and we're running JD Edwards at Fairmount. We looked at the two and said IFS is newer. We like the user interface better, it's more modern, let's all standardise that. So, the first thing I needed to do was in 2019 was migrate all the Fairmount Santrol sites onto the IFS platform. We did that. We broke the plants into six waves and based on what the value of the synergy was, we picked the facilities based on those six waves and then we migrated each of those from Fairmount onto the IFS platform and that made things a lot simpler. We weren't integrating between an old JD Edwards and IFS any longer. That let us get rid of some modifications and enhancements and other things. And it was a pretty good fit. There was very little that we had to do to accommodate fair amounts practises. We bought Novacura at the time so we could have a more of an automated loading solution for the plants to use. We've since retired that because Cloud has the capability to do that customization. So, we've done that internally and that's been a big opportunity for us.

Slide: Covia’s Applications

• We have a complex environment at Covia. We have some very complex order to cash customizations around some unique things in our business processes that would just not be common things as far as how we package and ship. We do delivered pricing for some products, we have to bundle the freight and the product together into one. As noted here, we've got 30 different applications, integrations, and some of them like this logistics interface alone that has about 14 different interfaces within there. There's a whole other page for that, so you can see there's a lot of interfaces and a lot of customizations. A major customization for key functional requirements around our order to cache process, and in fact like this, this interface here is about 300 pages worth of business requirements documents for just two of the interfaces that go between there and then there's another 10 or 12 on top of it. It's a technically complex environment. When we looked at using ifs as a hosted solution, the conclusion was that, we had one particular challenge that was not we're not able to be overcome. But the other thing is we're more heavily modified. It seemed like we would be better off continuing to run this more ourselves, and we give us more access at like the database layer. So, this massive set of interfaces here all runs at ODBC levels and that would all have to be uplifted to be hosted by IFS or anyone else. So, we were comfortable with the with the servers and the architecture we had in place. So we decided to stay on premises with our installation.
• Initially we had some performance problems with Linux servers and then we replaced those with Oracle database appliances back on Apps 9. And we were really happy with the performance of those. So, we we've stayed with those since and that's been a good solution for us, for our requirements and the technical limitations that we have with some of our interfaces.

Slide: IFS BVA / URA

• I'll talk about our Apps 9 to Cloud journey. The way we started was we engaged IFS in a business value analysis and upgrade readiness assessment. And we did that in the fall of 2021. During that process, they identified with Covia, I mean, this was really a good process based, function based work session, where we went through, we mapped out the processes with IFS, identified the various pain points. Tried to come up with a value assessment for those. And it came up with a collection of these. And there were 187 total. So, things as large as for example our company had reorganised and yet our Apps 9 system was on the old organisation. So, we said let's not just up keep the data as it is. Let's transform the data to match the new organisation. So that was something that was added to the project. Also some margin reporting on some of our services wasn't available. It wasn't captured in Apps 9. So, we changed some configurations and processes to be able to capture that and report on it. It was a good exercise. It kept us focused on what the value was for the upgrade as opposed to just making it in a technical upgrade. And also, I think it's also good for the business to be involved. The functional organisation, it builds commitment when they're talking through and they're invested in this and they're starting to hear about opportunities and see that there's some attention being paid.
• So that was the business value analysis that was undertaken early on, took about what maybe a month or so and then we also had this upgrade readiness analysis where they went through a series of surveys and collected information about our Apps 9 environment and basically identified which modules we currently run versus which ones we would run because those get repackaged and broken out in different ways from version to version. So, they did that. And we also added a few things. We added a group consolidation. We added that to our suite. We added a series of dashboards to Cloud that we hadn't had an equivalent of in the past and some other things too.
• And then IFS the process is, they basically they take all this data and they put it into a series of spreadsheets and systems that they have that generate what they call it a preburner didn't get too close to that, but they have the scope tool that lays out all the scope and it does estimation. The big thing for me is it lays out all the files that you have to migrate, so you know which ones have to come over and which ones don't based upon the scope of what you're using. Because it's such a big application obviously. And it also gave us our implementation tracker which included a lot of different information so we knew which reports we had to uplift, which mods we had to uplift. It basically gave us a whole way of tracking that. So that was just their standard approach. So that worked out pretty well. I feel like that gave us a good start to knowing what we had to do.

Slide: Covia functional project organisation

• Just to give you an idea, the way we approach the Cloud implementation. This basically just shows you the number of people that we had at different roles. We had a steering committee, we had a project governance committee initially. The thought was this group would decide which changes we accepted and which ones we didn't, expecting a large number of things to come up where people were going to be asking for functional changes. This quickly became unnecessary. Very early on, there wasn't really much to consider, so we just banded them and fortunately that turned out not to be needed. But that was the thinking there. We had like a project management team and we broke it all out by function as we did here which I think was good. Could also do it by process, which would be good like order to cash or procure to pay, but we did it this way. We did a lot of our testing by business process like order to cash, procure to pay. The circle shows how much time we needed from each person, whether it was full or part. So, you can see where the where the effort was required, and how many people we needed. A lot of people in accounting. A few from FP&A. Tax was minimal. Operations had a few people working really hard. Logistics was pretty minimal, because we weren't changing the logistics system. We just had to make sure the interface is stayed intact. Procurement had a smaller team and it's really interesting because procurement, there's almost no modifications at all to procurement. So, things are very easy for them. They have very little work, everything works right on the box. Nothing to go back to developers for, so they're living an easier life than most relative to what it could have been. And I think they had requirements early on, but they weren't the squeakiest wheel when it was implemented currently in Apps 9, and now they're reaping the benefits. So, if you can avoid a lot of customizations, that's really a beneficial thing. We removed a bunch when we went from Apps 9 to cloud. We took out about half of them, but there was still a lot left in there are the ones we could take out were mostly smaller ones, but we went through a process of really making the organisation justify every mod that they had from Apps 9 and why it would have to be carried forward. And we got rid of some silly ones, but there were some the big ones, unfortunately, were the ones that had to stay because they were so foundational.
• Commercial was also a big team because it's also included sales, inventory and operations planning groups, the logistics and all that. So, there was a lot to this group too. I would say commercial and accounting and we're probably the biggest groups with operations for our environment and we had a little bit of work for projects as well that has since dropped off. We've limited the use of the projects more to financials over time just for the financial tracking more than anything else. Though there there's a continued thought about maybe trying to do more with it, but right now that's how it's working for us.
• We had business analysts who were internal from IT largely and then we also had people from IFS as well as contractors that we brought in for that. This was our functional team. I don't have the technical team here, but I can tell you we had three full time IFS developers internally. We had two SSRS report developers to uplift all of our reports. I think we had about 200 reports, something like that. And then we've got a system administration team who works with IFS on our installations we had. The system engineer help with the installation, and then we use Re-Quest to manage our database. Re-Quest has been really helpful to us in managing our database tier. So, there are continued partner with us.

Slide: Upgrade Readiness Outputs

• This is the timeline that came out of the readiness output and I have to say, when we were going through the process of estimating the project, we were asking the expert opinion approach and there was an interest in getting it done in a year. And there were a lot of people in IFS who said 16 months, 18 months, 14 months, 12 months and when they heard 12 months go, that's the answer we like. So that was how that happened realistically. They went with the answer that they liked, and they said OK, let's do that. But to me, it would have been if we wanted to be more realistic, I think we should have taken a more balanced approach, made sure we listened to all the voices, look to comparables for example, maybe do some of the work or use it based on other projects and things like that. So, this was where we started out. The part that ended up really taking a long time was where these parts here. The mods, interfaces and data migration, so this probably went for 12 or 14 months for the interfaces on mods. The logistics mod I was telling you about, is so complicated and it takes 40 hours to test it. And then once you test it, then you got to rework it and fix it again. Well, we had 28 of those cycles just for that set of mods right there. So, you can imagine for each of those, that's 28 weeks right there just for testing without any development, when you had months of development on top of that. It was a lot. It was because of the things that we were doing, the customizations, that's what makes it complicated, along with some of the interfaces. But the interfaces were all useful. I would say just that logistics interface was the most complicated of all because it's so tightly integrated in so many different ways. That's where we started on our plan.

Slide: IFS Cloud project timing

• And this is where we ended up. We went through the project as you can see, we were we're getting into 2023 now. We got all the way through 2022 and 2023. We were still doing our solution tests and some of the data migration work, and we were still doing some bug fixes and things like that, and the SATS, ASTS, etcetera. And then I came up with a complex go live plan that I put together. I was actually out for a week in Florida on vacation and I spent a few hours each day just working on the cutover plan because I could think there and got it together and I was pretty happy with how it came out.
• The go live happened on July 1st as noted here. We started at about 6:00 PM on Friday night and I think we were done and shipping by 4:00 PM the next day. So, the thought was it could even go into Sunday. And I think everybody was pleased that it went together so well. But like I said, I spent a lot of time trying to look for the critical path, trying to find ways of, of doing things at the same time. They wouldn't be holding things up and seeing how much we can work ahead, and spend a lot of time trying to get that right and that went pretty well. It was viewed as a real success. The company was excited and happy with the results, despite taking more of an effort, but they recognised how monumental it was and what an effort it was, and they were very appreciative to the team and others.
• And then we had a period of about four weeks of what we call hyper care. So, every day, multiple times a day, sometimes we'll get on the phone. Anybody has an issue you can get on or we'll work with business process owners, they can get on. We can talk about what do we need to do to get things working, and we just do that right out of the gate. So, we're right on top of it. We're not waiting for them to log issues or anything. We're already in their face. How's it going? What's up? That really makes a big difference and I would say you could even have a rougher go live, but if you have really good hyper care, then that can make up for a lot of it. And this was all viewed as a success because we didn't delay the month end and that was the big thing. Can we do all this without delaying month and close. And we did that. That was a big effort to make that work out with finance and it felt really good to get that done. So that was the Apps 9 to cloud project.

Slide: Cloud Implementation – Lessons Learned

• The lessons learned from this, I put down communication was a strength. But I also see a lot of opportunity there too because I feel like as much as you think you're doing it, you could always do more. So, I put that number one.
• Sponsorship is also very, very key for the project. We had an engaged steering committee, we had leadership who insisted on getting it done all the way up to the CEO. They knew how important it was. They let us defer all the other projects for IT, so this became the sole focus for probably a year and a half. All other things got put on hold. So that was that was unique. And that was helpful to have that support where we could do that.
• We relied on partners. We worked with IFS and that was very helpful, had a great project manager and consultants. Ahead ERP handled our data migration. They had to do some transformations. We use the MTK Toolkit and Ahead ERP, they do great work. I was very impressed with Ahead ERP. I would use them again. In fact, the company I mentioned that separated from us, Iron Oak is engaging them right now to separate the data into their own databases. Re-Quest has been great. They handle all of our database administration. They've done things at our request like enabled automatic refreshes, so every night we have an environment that refreshes from prod. And people can go in there if there's a problem that happened one day, you can go in and see it the next day. It's super helpful, even the functional organisation really likes it. They can go in, they can try things. If it blows up or it doesn't work like they think, no worries. It goes back to the way it was overnight. So that's been super helpful. And then YNS Consulting is a consultant that's worked with us for a long time who is an outstanding finance consultant who really understands our data and our processes all the way through. So those are the people that helped us. I would say all of them we're super helpful to our success.
• Having hyper care as I mentioned made a big deal. Giving some recognition, acknowledging team members and individuals, some letters went out from the leadership thanking people and such.
• Then we immediately went into a release upgrade shortly after because we went live on 22R2 and we were already a little bit behind, and we had heard what you want to take service updates and releases right away. Well, I wasn't really sure about the difference between service updates and releases. I said, let's do a release and that was the big one, compared to a service update, which is a little one. But we were better off for having done it. But the other thing is too, it's a long process and you have to make sure that you're enjoying it, because people will work so much better and more creatively and work harder, if they're feeling appreciated and motivated and encouraged. And it's a light hearted environment, I think people work well and so that was something that worked well for me.
• I mentioned the estimation aspects of it, so getting multiple opinions if you really want to try to hit that number. If you're trying to look for someone to tell you a number that you want, then that's a little different, but if you want an accurate one, I would probably make a point of trying to get as many perspectives as you can and hear everybody.
• The mods timing that was the biggest challenge for us, that took the longest.
• Data migration was also a bigger effort partly because our transformations dragged the process down a bit. So, there was just a lot of work to do with data migration.
• And then staying current. We went to a release upgrade. It took a few months after the cloud go live, and that was a good move.

Slide: Pursuit of Evergreen

• But then we hear I'll show you what happened after this in our pursuit of Evergreen. We did the go live, and then we went to a release upgrade from 22R2 to 23R1. We started in October through November 2023. That took about 12 weeks and four weeks of development, so four weeks of testing and four weeks of troubleshooting. We thought coming out of that we could probably do it in 8 to 10 weeks, maybe 6 to 8 weeks. And companies do this a lot faster. It takes us longer because of our mods and interfaces and the amount of testing that has to happen with these. But we're getting more efficient as we go. Each one's getting a little better.
• Then we fell out of Evergreen for some time. I would say, until August of last year we got some other priorities. There was the energy carve out going on and things like that. We had wanted to do a release upgrade earlier in the year, and we were just too overloaded, distracted with other business initiatives. So, we said, OK, what we've got to do something we should at least take a service update. So, we did a service update from SU4 to SU16 in the third and fourth quarter last year. And we had very few issues. It was kind of crazy to me how few problems we had identified during the course of testing, like maybe two. And so, we did that over four weeks, two weeks of development, two weeks of testing.
• And we're currently upgraded to 24R2, and we're planning to be ready to go live in April or May. There's another group who wants to test their applications with IFS after we finish IFS testing, just because their consolidation system is so new, not that it should be something we should have to do, but it's more for their comfort level. They said they want four weeks for that. We're going to be done. But you can have four weeks to do that testing if that gives you the comfort level, and so we're allowing time for that. The development took a little longer because we were jumping three releases this time instead of what one or two, and that took about maybe 5 1/2 weeks. There's often a little bit of a probably ran into with the build. Sometimes the build won't quite finish. You have to troubleshoot that with IFS. That was a common thing, so we had to do that this time, and that took about a week to get that to work through with IFS. But we did that. And then once you have the build, that's a great feeling to have that work out. And it comes together. Sometimes it just takes a little time to work through what's holding it up. And we're in the second week of testing right now and I think because we figured some things out from before, from the last release upgrade it, it really made things a lot faster in terms of testing. And like I said, we've got maybe five or seven issues total. And most of those are resolved already. So, there's very, very few issues coming out of testing. Some of the problems we had in the first release were because there's things that you have to do that you lose during a release, either configuration or things like that, that we just didn't know about or didn't weren't prepared for. Stuff that we were just out of practise of, things that we could have known that were differences in our test environment from production that would have to be changed for this particular type of testing. We got all those down in a list. I had a list of lessons learned that was as long as the project plan roughly for the release upgrade. By the time we were done so. So that's what I'm going to share with you here.

Slide: Pursuit of Evergreen – Lessons Learned (1 of 2)

• When we did our release upgrade in our pursuit of Evergreen, this is what we took away. I put these into our plan to consider at each of these stages. So, in planning development, test, planning, testing, deployment, all of these things. There's a lot of little details in here. I'll just try to cover some of the highlights. We talked about when to take these SUs quarterly releases once a year. Ideally, though you could go 18 months, but it's usually not worth it. It's better to keep people on a yearly schedule. Look for new bugs that come out from the release. There's always going to be some. A lot of people didn't test their inquiries, they did the end to end transactions, but then they didn't test their inquiries. So, we encourage people and say, hey, if it's important, go test it now while you're doing these end-to-end transactions, because it's going to be affected. Try to stay to the code freeze. We'll do direct deployments of code changes and emergencies, because once you upgrade your build place to the new release you can't build deliveries anymore in the old one. You only have the one build place, so if you want to make a change you've got to push it directly into the production environment. You may still have a test somewhere, but those are direct deployments and we try to limit those just to emergencies. We've been pretty effective this time, though we're doing some things for the tariff response here in the US.
• We found out that you can't change the service update after you start doing the release, but somehow our developer just did. I don't know what he did because we started with two and then he said, oh, we're going to four and I go Oh well, how did that happen? We already started on two. So somehow, we figured something out. But before this, the understanding was that if you start on two, you're going to go live on two. I don't know what he accomplished, or if he got some special arrangement made to take some fixes from four or something like that for 24R2, but that's where he is.
• We found some vendors we're very slow to respond. Banks in some cases or third parties with our testing. So, getting them engaged, getting a statement of work, something early on, getting people, that is saving a lot of time. That's what caused our first release to take so long was waiting for banks and things like that to get back to us. It just took forever.
• You could copy interface files from prod if SAS vendors are just not being responsive. Or you can use notepad or something.
• Remove your customizations if you can. We haven't been able to do a lot of that during releases and the service updates, but we did a lot when we went to Cloud.
• Permission sets. So when projections change, you need to look at the security because the security is based on the projections and if the projections change, then it falls out of that security. So, we realise this after going live with the release that a lot of people have lost their security, and we gave people full access to do testing so they could test everything. Well, that was a mistake because we really want them to test their security too. So, this time we said we'll give you full access, but first of all, you should test your security, so that way you don't miss that and then have to deal with that immediately after go live. So that was something that surprised us after the first release upgrade.
• We run planning and scheduling optimization and there's a need to check for that if, but most of you probably don't, but if you do, that's just something to be aware of. Special documentation.
• In development, in 25R1 or 25R2, some of these things are deprecated. So using SQL versus substitution variables in lobbies I think is something that we need to be doing now. And then replacing SQL custom events with workflow. I believe that's a requirement beginning of 25R something, so that's something your developers can do. I just asked our developers to do that, wherever they see that and as they have time in between, let's just do that.
• And then the installation files, delete or obsolete. I think that has to do with the files maybe on the database, but our system admins would know that.
• Good to know about major changes like for RMAs. The functionality was moved so when our testers got into it, it's like well, it's not there. Oh, it's in a different menu now. It's on a different screen, it's completely changed. You need to know about those things or else you'll find them out later.
• Important to include taxable and non-taxable cross-border orders since that's important, and I just added testing tariff processes because those are unique if those are in place.
• And, I mentioned having users test their prod security initially to identify security issues before giving them open access and the non prod.

Slide: Pursuit of Evergreen – Lessons Learned (2 of 2)

• For lesson two, I would say you want to refresh your third party environments. So, our logistics system and our tax systems, we refresh those test environments at the same time so everything's in-sync. That way you don't run into erroneous issues just from things like that.
• A few of the other highlights when you get into testing, instead of turning a bunch of people loose, have somebody do a few of them all the way through to financials because if there's a problem, you may have to redo them and you might not find it out until it's invoicing. Then you have to redo it. We almost made that mistake. We didn't. But that's a good practise and I'd say keep moving with validation as you're going through the test. Just because an order hasn't been validated yet, go ahead and start invoicing it, because if there's a problem during validation, you're going to have to redo it anyhow. And if there isn't a problem, well then, you're that much further ahead. So those are things like that I would suggest.
• You got to test your expected bug fixes. We have a list of things we're looking for.
• Refreshing the security cache is important. A lot of the just the environment setup.
• One thing is to keep an old environment in the old release. We didn't do that last time. And then we said, oh, well, how did it work before and it's like, oh we don't know. We overrode it. So everything else had been upgraded, so we got to prod. Now what we're going to do is keep one on the old one. So we have a point of reference. So that's a good lesson that we learned from that.
• Custom tables retained during upgrade and update date formats.
• One thing we do too with Re-Quest is when we do a deployment, we get them on the phone and we say, do a guaranteed restore point which is basically like a snapshot of the database. And then if there's a problem, they can just flash it back instantly to the previous point. We do that for our database, and then we also have our system admins back up our middle tier servers. So, if something went wrong, we could roll back, we can do that. And we've had to do that. We haven't had to do that much, but I think we had to do it one time and it was a good comfort feeling to know that you have that if there's a problem. I don't know what features are available to everybody. If you're not on premise, but that works well for us.

Questions / Answers / Feedback / Responses:

• Q: You decided to move away from IFS hosting cause of one particular reason. Could you maybe just elaborate on that. What was it that pushed you into self-host?
• A: The one reason was the ODBC connectors that we required direct database access in order to interface with the logistics systems. And that's just not supported by hosting basically. You can't get into the database layer directly.

• Q: You have a good number of old legacy systems. Did you pick them in batches to move them to IFS or did you just create a mop up for everything and then put it on IFS?
• A: This goes back to when we had to move from Fairmounts JDE systems on to IFS. Some of these systems, like these other load out systems, those were connected to Fairmount systems for a particular site or set of sites. So, as we move those sites in a way, that application came over. So that was really the only time that we phased the applications. When we did the upgrade to cloud we brought all the applications along all at once. So that was a Big Bang approach.
• Q: You said it's a Big Bang approach. And how did it go?
• A: It went well and some of our applications are so tightly integrated and we wouldn't be able to operate without them. For example, we wouldn't be able to take orders without a connection to our tax system. We wouldn't be able to enter the orders. We wouldn't be able to ship without the logistics system. So there's some things that we just absolutely have to have that we can't operate without, and when we did the Cloud implementation, we just did it all together and that was the right choice. It maybe took a little bit longer, but I think it was the right choice for us to have everything continuing to run, since some of these were kind of specialised for some parts of the business.

• Q: You've come from Apps 9 going straight to Cloud. Your users, what was the transition like from them, going from the EE client to the arena client?
• A: That's a great question, and that was something that scared us a little bit before we got into it. We thought, oh, the user interface is different. We were prepared for this. We're really going to have to do a lot of training and communication around this. And we found very quickly, people seem to pick it up and within a short time, our lead of finance was saying she liked it better than the Apps 9 interface. So, it doesn't take long. There's a few things that are a little different, but after you learn those, the rest of it works well. And the fact that you can resize things, you can go Ctrl F to find a word on a screen. There's a lot of things like that you could do it in a browser, you just can't do in Enterprise Explorer, and that can be really helpful. So that was less of an issue than we expected.

• Q: With regards to the updates in Cloud, you mentioned that every time you get a release or an update, there's some development. Is that CRIM development, like rework of customization? Or is that more testing to make sure the update hasn't broken any CRIM?
• A: Well, for us, it's both. We have to uplift our CRIMs. So, you run the Update Analyzer. There's different ones for releases and then it tells you all the areas where you've made code changes that IFS has made code changes in the release. And then it says, OK, these are the areas you have to go look at because it didn't merge automatically. Where there aren't changes and things can merge, it merges to all the configuration. But where there are changes, you have to manually go into those and have the developers see what was changed and see how to fit it in.

• Q: With regards to CRIM. Are you actually developing it? What I mean is traditionally you'll create a custom field or a custom event within the client itself. I know certain partners are pushing forward with all developments done in build place. Are you guys following that course of action as well? So any configurations done in build place and rolled out that way?
• A: We do, and in fact, we've had people try to get the screens configured just how they want and then to find out that a lot of that got lost during the release upgrade. So, if you do that through build place, it'll stay through releases. So that's the way we're doing it this time is we're putting all of it through the developers to be put into the build that way. It'll either have to be merged going forward or it'll just carry forward.
• F: Yeah, I know certainly in the UK, one of my very good friends is the head of technical at Arcwide and speaking to him, they're pushing all their customers to use build place in Cloud because it simplifies in some respects, it mitigates any risk of lost CRIM during these upgrades.
• R: Yeah, it's the way to go. That's exactly right. I would put everything through build place. That's been a lesson that we've learned through some configuration work that we've tried to do. So that's what we're doing. We do things at the customization layer. And then we also do PL/SQL development for some of our deeper mods. So, we do both, but we try to do as much as we can using that customization layer that IFS makes for custom events and things like that.

• Q: Do the customizations in the build place as well as the modifications?
• A: That would be a question for our developer, but I think that's the case. I believe we do everything through build. So, even if we do custom events or custom fields, that goes into our requirements document, our developers do all the work. So, it comes together as a single unit and it gets deployed all at once. So yeah, there's no need for anyone to go in after a delivery and add things or redo things. It's just built in.

• Q: You said that you went out of the Evergreen due to being behind on the releases. Now that you've caught up and you've got that plan, is that your plan for the future to stay current? How often as a business do you plan on taking those upgrades and the updates moving forwards?
• A: That a good question. The reason we decided we had to do something was because we had a number of out of band fixes, where we had a bug, we need IFS to fix it. It was in a later service update. Oh, that's not in four, that's in five or eight or twelve or whatever. You have to take a service update. They did that for us for a while. And then I got a call from Tony Johnson, who heads up support and says, hey, you guys need to take service updates and he explained to me that the way the policy works was that they would do out of band fixes for you if you were within three service updates. So, you have to take it quarterly to be to receive that level of support to get the customised bug fixes. If you don't do that, they won't back port it for you more than a three service updates, so that's the ideal. I think you have to take service updates quarterly. And then you need to take releases probably once a year. You could go 18 months for a release because they are good for two years from general availability, sometimes they'll do some additional service updates, but they come out with 24 service updates usually for a release. So, it's good for two years and it's easy. The organisation I'm working with, we decided we just wanted to at the same time every year. So, it's like audit or something like that. It's just a process we go through at the same time, everyone can schedule around it. So, we're going to do that. If we get into trouble though, we know we could extend six months just because we've got that runway.

• Q: You mentioned that you had a bunch of complex modifications just like we do. So, my biggest interest is on those. What's your experience on how many were converted to Cloud configurations and how many were remade as modifications. Do you have estimates on the rough split of those, from Apps 9 to Cloud?
• A: Our general approach is to tell developers do everything you can in the customization layer. That's their preference too, is to put it all there so it uplifts more naturally. I don't have the metric on it, but I'd be happy to ask our development lead about that and get you an answer if you like.
• F: I'm asking because we are wrestling with this topic right now and we don't know much about what is possible in Cloud. We only hear that there are so many possibilities that don't exist now, but whether it's true or not, we see you later in the project. That's just what what's the general experience? Are there new capabilities where you can get rid of your existing configurations instead of just making them again in Cloud?
• R: To some extent the BVA and the readiness assessment helped. I think you had said you were able to eliminate 50% of the customizations, but now we're talking about those that you kept, how are they handled.
• A: Yeah. And we eliminated them without really looking at Cloud specifically. We went back, we challenged each of them, and we did the same for reports. We got rid of probably 60% of the reports and things like that. So, we made people re-justify every one of them before we brought it up. We had done that a year earlier because we were preparing for Apps 10 and then we had to put that on hold for business reasons. But that was a good process. But yeah, the ones that we had to bring forward, I believe those had to stay in PL/SQL for the complexity, but I think usually our enhancements, combine custom fields, custom events and then some PL/SQL logic together, but they do as much as they can at that customization layer to the degree that they have the ability to do more of it there versus an Apps 9.
• R: it's a really interesting discussion because there is a lot of trepidation when you start talking about getting rid of customizations. And I think the process that that you all went through, even early on as a business really force that reflection of, can you make a business case for this? Is it actually necessary? It's such a valuable exercise because often they were made at one point and maybe they were necessary then, but no one necessarily wants to do that work to reflect upon it, and figure out what can be simplified, and so it just stays there. Even if it isn't actually required.
• A: Just to add to that, we have a demand process we use internally for IT demands and then people put things in, where they're asking for a request. And as part of that, they have to include the business value, like how many hours they're going to save, or dollars they're going to save or increase one or the other. And then, we look at them with the business process owners and say, OK, here's how long it's going to take us. And we look at it collectively and usually it's clearly over here, it's clearly over there either, like, oh, this is a quick thing that's going to save you a lot of time. And there's some things where it's a big effort and it's not going to help you that much. Let's just defer it or not do it right now. And then things that are larger, we take those to a C-level, meeting with our leadership and have them approve anything over 40 hours or $10,000. And then they make the decision about what we do and don't do. And that takes us out of the role of trying to decide an arbiter of these things on our own. And we and we try to do it everything on a consistent on a level. Use ROI based on hours, ROI based on dollars, and that's been a good process. So that's we did with all those mods. Basically, we took the same approach. How much is it going to take or cost.

• Q: I was just wondering about the permission sets because that is what we are facing starting a project now and we see that it is a very time-consuming thing to do as part of the project. Did you did you find any good ways of handling this or is it just manual work, finding correct projections and granting?
• A: Yes. It was time consuming. We had one of our consultants I mentioned from YNS who was really strong with security. She put together the whole plan for us. She'd done it for Apps 9 and reworked it for Cloud. We have a support analyst who spends probably half his time doing security, maybe 1/4 depending on what's going on, but it can be time consuming. I think IFS was planning to do something in a later release, maybe even this one where they're going to make security configuration, some tools or things to make it faster and easier, but we had to lay it all out in a spreadsheet and it can be time consuming. I would probably use IFS to help with that.

• Q: Do you use the projection change log when you do your build? So, there is one where they notate all the projection changes that happened. So that's what we used to go look at, and then we reviewed, are any of them relevant to any of our functional areas. You can target where you need to pay attention to, where you need to test.
• A: That is awesome. That might be part of what the developers provide. We asked for them to identify areas that we need to test based on where they're seeing changes and where they made changes so they give us a unit test. They say go test this type of order or this thing. So, they give us that where they can have insight. But that's really good. I'm going to check on that. It's probably common knowledge to our some of our developers, but I'm going to ask just to make sure. Thank you for mentioning.
• Q: Do you know where the project change log is available from?
• A: Yeah, it's in build place when you have your build deployed. Then you can grab logs, but it's called _projection_change.log. It's in a zip file that you can download.

• Q: I don't really pay a lot of attention when we get emails from IFS, but one that did come in the other day was about the depreciation of Crystal. Thankfully that's happening. Is that going to affect you guys?
• A: We're on SSRS so that doesn't affect us. We've been running SSRS and that works pretty well.
• R: For some customers, it's going to be a bit of a job here. For us, we only have a handler, Crystal reports. But I know a lot of IFS customers do quite heavily rely on Crystal reports, so it's going to be a bit of a job for them really, but I presume there's some additional functionality, new ways of reporting in cloud anyway.

• Q: With this new Evergreen approach, with the constant service updates and release cadence, have you looked into any automated testing tools out there instead of obviously taking the burden away from bringing people out of their day jobs which is a real frustration for us. We get push back from the business and we've got to pull operational people out to do testing, which obviously time consuming, etcetera. So, I was just wondering whether that you've looked at any tools out there which could help automate some of this repetitive testing?
• A: We looked at click learn because we use click learn to create our documentation. Apparently they can use that documentation to basically automate certain things, but we didn't get far enough along with it to see how that would work for us. We're also looking at maybe using flat files and APIs to load orders and things like that, but we haven't put anything in place yet.
• Q: Has anybody else on this call implemented any testing routines out of interest, because obviously click learn we've looked at and it's a very expensive tool. I think everything's going to be expensive, but I'm just wondering everybody else on this call has implemented any such tools.
• A: Yeah, we looked into it. We did it during an Apps 9 to Apps 10 upgrade. Because we've got an in-house development team, we looked into trying to write our own packages and what we were trying to do was trying to automate that whole process. I'm only telling you this to be honest and say we didn't get very far. We did try, we had some ideas and then we had a look around to see if there's anything automated that we could use for testing. I know it exists out there. We weren't able to do it in house to be fair.
• A: I think there is a way you can leverage postman for from an API standpoint to run some automated testing. We wanted to explore that, but we haven't had a chance to explore, but that's something that you can take a look at it and see if that's helpful.

• Q: My questions about base profiles. Did you have many base profiles in Apps 9 which you had to convert into context in Cloud?
• A: We did. That's it's been a while now, but I don't remember that being a big effort. I think we tried to use just one global profile for everyone. I think that was a best practice we learned.

Next CollABoratives: 

• TBC 10:00 AM US ET / 15:00 GMT / 16:00 CET
  Combined CollABorative: Tech Talk: An IFS Acquisitions Overview

If you are an IFS Customer and you do not have the next meeting invitation to this CollABorative and would like to join, please click here to fill out the form.