A lot of ERP work gets pushed to “after go-live,” and then it gets done in a hurry, if at all.
Learning the system, securing it, and deciding who runs it are three items that tend to get pushed out. Ken Foley, Vice President of RPI Consultants’ Infor Practice, returns to RPI Tech Connect to argue that ERP implementation planning should cover this work from day one
Drawing on nearly 30 years in the Lawson and Infor space, Ken covers role design across every CloudSuite application, the change control process auditors will eventually ask you to produce, and segregation of duties. Plus, hear why the first few months after go-live are busy enough with support issues that anything postponed gets postponed again.
If you’re considering an ERP project, this conversation is a must-listen before starting!
Interested in listening to this episode on another streaming platform? Check out our directories or watch the YouTube video below.
Meet Today’s Guest, Ken Foley
Ken Foley is a Professional Services leader with more than 25 years of experience in enterprise software development, implementation, and support. As Vice President of the Infor Practice at RPI Consultants, where he has served for nearly seven years, Ken helps clients prepare for and execute successful cloud transitions by combining proven implementation methodologies with best practice business processes. He is passionate about helping organizations get the most out of their technology investments and ensuring long-term value through thoughtful planning and support.
Before joining RPI, Ken spent over a decade at NTT DATA Services in roles ranging from Senior Solutions Architect to Senior Director, where he guided large-scale enterprise software projects across diverse industries. His depth of experience, combined with his commitment to customer success, makes him a trusted advisor for organizations navigating complex ERP and cloud transformations.
Meet Your Host, Chris Arey
Chris Arey is a B2B marketing professional with nearly a decade of experience working in content creation, copywriting, SEO, website architecture, corporate branding, and social media. Beginning his career as an analyst before making a lateral move into marketing, he combines analytical thinking with creative flair—two fundamental qualities required in marketing.
With a Bachelor’s degree in English and certifications from the Digital Marketing Institute and HubSpot, Chris has spearheaded impactful content marketing initiatives, participated in corporate re-branding efforts, and collaborated with celebrity influencers. He has also worked with award-winning PR professionals to create unique, compelling campaigns that drove brand recognition and revenue growth for his previous employers.
Chris’ versatility is highlighted by his experience working across different industries, including HR, Tech, SaaS, and Consulting.
About RPI Tech Connect
RPI Tech Connect is the go-to podcast for catching up on the dynamic world of Enterprise Resource Planning (ERP). Join us as we discuss the future of ERPs, covering everything from best practices and organizational change to seamless cloud migration and optimizing applications. Plus, we’ll share predictions and insights of what to expect in the future world of ERPs.
RPI Tech Connect delivers relevant, valuable information in a digestible format. Through candid, genuine conversations and stories from the world of consulting, we aim to provide actionable steps to help you elevate your organization’s ERP. Whether you’re a seasoned professional or new to the ERP scene, our podcast ensures you’re well-equipped for success.
Tune in as we explore tips and tricks in the field of ERP consulting each week and subscribe below.
Transcript
Chris Arey
Welcome back to RPI Tech Connect, the all things ERP podcast. I’m your host, Chris Arey, and today we’re going to be talking about where the energy tends to go during an ERP implementation. Most organizations like to focus on the build, the timeline, and hitting go-live, but it’s the things like user learning and day-to-day operations that tend to get treated as problems to solve after the system is live. My guest today argues that that’s a little backwards.
He also believes that learning should start on day one. He also says that there are plenty of operational decisions that need to be made long before cutover to ensure you’re not scrambling once the system is up and running. Joining me is Mr. Ken Foley. So, Ken, welcome back to the show. It’s great to have you, man.
Ken Foley
I appreciate it, Chris. Thanks for having me. I think this is number three for us.
Chris Arey
Yes. Yep, you’re becoming quite the regular here. And for those who haven’t had the pleasure of meeting you, it’d be awesome if you could give a little background on yourself.
Ken Foley
Absolutely. All right. So I’m Ken Foley, as Chris said. I’m the vice president of RPI Consultants’ Infor Practice.
So I lead delivery, reporting to Richard Lee Stowe. RPI Consultants is based in Baltimore, Maryland, and they’ve been around since 1999. They were a Lawson partner originally, and then obviously went over to Infor when Infor acquired them.
I’m responsible for delivery, as I said, but I cover functional, technical, and consulting services, and also we have managed services that we provide to a lot of our clients. And in terms of the products, I’m responsible for FSM, HRT, payroll, and the legacy Lawson S3 solutions.
I’ve been with RPI for about seven and a half years. I’ve been in the Lawson-Infor space for close to 29 years now. I was first a customer of Lawson myself. My first job out of college was as an assistant buyer at a biomedical research institute in Cambridge, Massachusetts, and I was asked one day by my manager if I wanted to assist with an ERP selection.
So back then — this was like ’96, ’97 — Y2K was a big deal back then. We were on a VAX system that was not Y2K compliant, four-digit year compliant. So, we had to go out and search. We looked at the incumbents, and then we looked at other products, like PeopleSoft, SAP, and Oracle.
And we looked at Lawson. We ended up choosing Lawson. So that’s how it started my journey with Lawson—that’s been a while. And then I worked—they asked me: hey, do you want to be part of the implementation team?
Yeah, great. Love to work with the implementation partner, learning about the, you know, the application front end. So started as a procurement person.
Then I started to help on the financial side, inventory control, accounts payable, all the modules within the financial system. And then the implementation partner showed me some of the technical utilities. How do you load data in and run conversion programs and all that? So that’s how I started supporting Lawson and absolutely loved it.
And that just took me from there. So anyway, you know, I worked in a number of customer success roles on Lawson. Then I started managing business analysts, and then as I moved on in my career, managing application support teams, then I went over to the network work and hardware side. So, you know, managing system administrators, network administrators.
And then managing data center operations and IT operations. So that’s kind of why I’ve always had an eye on, okay, post-go-live—what does life look like? How do we manage the ecosystem that we put in place for clients?
Chris Arey
Yeah, just a couple hats you wore there too. But I appreciate that. And I think your background in operations is going to play a unique role in today’s discussion. I actually want to start with a question for you real quick that’s going to frame the rest of our conversation here. And that is: when we say ‘operationally,’ what do we mean by that exactly?
Ken Foley
A little bit, yeah. Yeah, Chris, so what I’m thinking—it’s in terms of, you know, the background that I have in IT—it’s real-time, holistic understanding of your entire technology landscape. So the infrastructure health of your systems, how your software’s performing, security threats that could come up, and that could be
You know, stuff that will impact your core business services. And that could be internal or external threats and a lot of the times over the years, I’ve found, a lot of times it’s internal. And then, you know, to be more proactive about that and not as reactive, so you’re not firefighting so much—you have plans in place to address things as they come up.
You know, in your ecosystem and so forth. So it does require monitoring solutions of your IT services? What are you actually delivering as services to your internal customer or external customer? And inventorying all the assets that you have that are there to deliver these services.
Being able to connect dots, so that if one of your assets is degraded, not working properly—what services are affected by that, and how? Is it down, is it degraded? You know, you need a system that would be able to monitor that and then let you know, like on a dashboard: this service is degraded at this point, right?
What your internal SLA is with the customer is important—that’s your agreement that, hey, we’re delivering the service. If it goes down for whatever reason, we’ll have it back up within this certain amount of time. That’s an SLA. So a lot of that is in the operational context of providing services.
So for the folks that are implementing CloudSuite, I’m sure these are folks that would be checking this out. I’m thinking about understanding what it takes to administer your tenants. What are the roles and responsibilities of you as the client versus Infor for maintaining and operating these tenants? Understand what it is early on, so you can go through the project—you’re taking the time to learn the activities that are required of you to get done, to fulfill those responsibilities.
And, you know, making an educated decision that you’re going to contract help to support you if you find that you’re not going to be able to provide those services yourself day one. So that buys you time—you can contract a managed services company that knows CloudSuite.
And they can help ease you into taking over that role as the primary support for your tenants. And if you have to push off learning a little bit to beyond post-go-live, you’re still planning ahead of that—so you’re not thinking about this post-go-live, you’re thinking about it prior to go-live. So at least you have the plan in place to properly support the system out of the gate when you go live. So that’s what I would say on the operational front.
Chris Arey
Okay. Yeah, no, that’s good context there. Thank you. And it sounds like then that the message that we’re trying to communicate today is that folks need to be thinking about this stuff throughout the project. It’s not like a switch they hit, now they’re live, now you’re responsible for this. It’s like, no, this is an ongoing thing that really should begin at the project’s outset.
Ken Foley
Yes. Yeah. So obviously during the implementation, you’re focused on things like the tenant provisioning, tenant strategy, how am I using my tenants during the project? You know, what’s going to be my pristine environment?
How do I manage that? You know, when you have final sign-off on configurations, stuff like that, you want them in your pristine environment—whether it’s a setup of applications or system configurations that you want to store so that you keep them for every feature test cycle. As you go through your test cycles, you have got to account for async errors, right?
The async manages all of the processing that goes on your system when users submit jobs or whatever, and you may have errors that come up out of those.
So those have to be looked at, reviewed—you determine what’s the root cause of those errors, fix them, hopefully address them for the future so that you don’t keep hitting the same issues. That has to be looked at during the project, right? You also have to consider the CUs. They’re getting updated monthly.
So there’s like, you know, quick emergency fixes or whatever that they’re delivering. They’re applying those. Your tenants, right? It doesn’t matter if you’re live or not, they’re hitting your tenants. You just have to be aware of that. And then they have the biannual feature releases, you know, so April, October, or November.
You have to be aware of what are the features that are getting delivered. How does that affect your project? How does it affect the configuration? You know, you may have put together a design.
And then something’s changed because of a new feature, you know, and then usually they’re like toggles. You have to determine do I enable the toggle and see how it works and figure it out and then you know adjust on the fly with changes like that.
I was telling you earlier, Chris, at some point, it’s like kind of building a plane as it’s flying, in a sense, or we’re going to take out this row in order to make some more leg room for first class or something, you know. That just happens after take off. So you just have to be able to pivot. You’ll continually have updates, you’ll continually have some changes and all that. But you need to be ready because this is going to happen after you’re live.
You might as well figure out operationally what’s my approach to addressing change in the middle of the project. So that you’re going to actually have some test runs with CUs, you know, with feature releases and all that. So the process of learning what’s included in those features.
Where do you go for the information to review and all that? How do you turn them on? How do you test them to see what it actually changes, you know, firsthand? That is stuff you can learn now as you’re going through your project. So by the time when you go live, it’s gonna be second nature to you guys.
Chris Arey
I really like that framing of the building the plane while it’s flying. But you also make a great point here. It’s like, why wouldn’t you try to get ahead of all this stuff, knowing that eventually you’re going to have to own it anyway? Really good.
As I understand it, you’ve got three buckets that organizations should be focusing on operationally as they’re going through the project. I believe the first one that you kind of outlined here is security.
Ken Foley
Right. Absolutely.
Chris Arey
Tell me more about that.
Ken Foley
Yeah, okay, so application security. Roles. There are functional and technical roles. There are varying security models for each of the modules or applications, and they all tie back to Infor Federation Services, where you set up roles and you add users to those roles.
So FSM, HRT, payroll, mobile supply chain management, XM, WFM, Birst, CSF Analytics, HRT Analytics, WFM Analytics, EPM—that’s the BI/FSM stuff, the cubes along with document management. There are all these different applications and they all have their own security model.
Like, for example, IDM has an access control list. Depending on your document type—it could be an invoice type, it could be a check, a payroll check, you know, whatever. There are these ACLs that tell the system, okay, if this person has this role, they have the permissions to access that document or not, right?
That alone you have to incorporate, along with the other roles that they may have for FSM—you know, they may be in FSM, XM, or CSF Analytics, which is Birst-related, right? So all those things require access but each one of them has access that is dependent on certain roles that are assigned to them in IFS.
You have to have a comprehensive view of all the applications a certain persona is going to need access to and what type of access. And be able to kind of put together, you know, almost like a roadmap, you know, for this persona and your organization.
They should have these roles in order to do their job. It’s really understanding what’s the model, how it works for each of these applications. And then how do we, in IFS, assign the appropriate roles to them, so that we don’t have to think through it every time? If it’s a certain persona, we know we’re going give them this when they’re hired. You know.
Chris Arey
This sounds like a good example of something that teams can get ahead of before go-live. Because I can see like once you’re live, the kind of headache this could have for folks who hadn’t been proactive about it and are having to assign different roles and permissions to view different data and different applications and the mess that causes. It sounds like there’s a lot of thought that needs to go into role security. Do you find in your experience, is that something that teams underestimate?
Ken Foley
Yeah, a little bit, especially because sometimes their approach is influenced by their experience in the Lawson S3 world.
It was basically an application, and all of your roles and security classes were for that application, right? I just reeled off how many applications have a different security model, right? So there is excellent reporting for security in the system.
However, there is no one silver bullet report that’s going to give you the comprehensive view and context of what access an individual will have in all of those applications I listed. Okay. So as you learn the modules or applications, you know, you also need to learn how are we going to secure these things.
Someone’s got to think about how the organization should go about securing that functionality, right? So someone has to focus on that and then piece the whole thing together to figure out, okay, this is what it should look like. You know, here’s all the personas in the organization that will have access to something in the system. What should that look like for each of those personas?
Chris Arey
Yeah, that’s a lot of work.
Ken Foley
So then it all goes back to IFS, right? When you are provisioning a user, you’re assigning roles at the IFS level, and then things propagate down into each of the application modules, and then they will have that access. Yeah.
Chris Arey
Got it. Dang. So definitely something that the teams need to spend some time on and not overlook. All right, cool. So moving on to your second bucket here, we have technical development lifecycle. What can you share there?
Ken Foley
Yeah, for sure. And I kind of cobble that together a bit with change control, because change control is a way to govern and manage what you’re deploying to your production system, which is the tail end of the technical development lifecycle. So, change control—I want to start off with that. It’s not organizational change management. Some people may get confused by that.
This is more of an IT process—policy and procedures to manage change, additions, and removal of IT assets. And assets could be hardware, software, you know, reports, coding, anything related to providing IT services, as an IT asset—so any of that stuff in a technical ecosystem, and determining through this process what are the downstream impacts. So if I change something, what does that affect? So knowing that up front. And that’s why we were talking a little bit about connecting dots with IT assets, understanding how a single asset affects the delivery of a service.
Like, for example, Active Directory—we can call that an IT asset. Well, without it, you get access to no applications if you’re going through Active Directory for authentication. You’re not getting access. So AD is a key IT asset that affects many, many, many, many services, you know. So that’s kind of how you work it. You know, it’s almost like a tree.
That you go through to determine, okay, what is the asset, what services it affects, and how does it affect it? So AD being down, you’re not accessing an application system down versus degraded. If AD is degraded—meaning you have multiple servers and the main server went down and it’s repointing you to another one, but the other one could be in an office in another state or whatever. It could be degraded in the sense that it’ll take a little bit longer to perform for somebody who’s in another state as an example.
Okay. If you have a mature change control policy and procedures, it’s my opinion you should start thinking ahead of the go-live. Okay. How are you going to introduce Infor CloudSuite into the environment, right? What aspects of CloudSuite affect what services, and so forth. Start kind of building that out and understanding, especially if you have like monitoring and you’re monitoring IT assets, you’ve got to include these assets now in your system for that type of stuff. As I said, this is closely tied to the technical development lifecycle.
During your implementation, I’m sure you’re picking, you know, as part of the tenant strategy, you’re picking a tenant where development is going to occur, right? And I would argue you pick one and you stick with it. You don’t do configuration changes in this tenant and, you know, heavy development in this tenant, and all that. Pick a tenant, do all the development there, and then you deploy or copy to other tenants, right?
You’ve got one tenant that’s your development tenant. You’ve got a test tenant. You have to perform either a user acceptance test or a unit test. As such, copy everything you developed or configured over to that tenant from the development tenant so that everything is in sync. And then you go ahead and you can do your data migrations or whatever, you know, your builds, what have you, and then prep the system.
From there your users are able to validate their login attempts to the system. They have an account. At that point in time, they probably have some semblance of security, you know, depending on where they are in the project.
And then they should be able to access the menus they need to access, the pages that they need to do, and then the actions they need to be able to take in the system. So, pick a tenant for development, please, and stick with it.
You have a tenant strategy. So you know what’s going on where. Then you have a playbook in place on how development items, technical assets, whatever are copied from one to the other. And you follow that procedure each time and stick with it. Okay. And if you’re going to be using change management functionality—Infor has that, okay?
In the configuration console, you can actually tag configurations. You may have a big solution where you have three or four configurations. Tag them all the same so then you know that they’re related, right? And then there’s the whole process of you know tagging and then bundling them, and then bundling makes it a lot easier to propagate them over, deploy them to another tenant. All right.
Within change control or change management, you probably have it in place because you get audited, and auditors are looking for changes to your production environment, right? You may have a change control system where you have a change control number that’s tied to the change that you’re trying to deploy.
So perhaps, you know, the tagging—you may use the change control number there. So it makes it easier for you to pull changes out, report on them. So when the auditor is there and you know how it goes, the auditor will pull, okay, I want this change, this change, and this change. I want you to pull everything for me, all the documentation, and I want to see date timestamps of your code.
And it should align with what’s on your change control document, right? So if you tag stuff that way, it’s a lot easier to report on it with the tags so that you can tie things together and show that to the auditor. Makes your life easier, makes the auditor’s life easier. So, that’s my spiel on tech development control.
Chris Arey
That was really good, thank you. I appreciate that, especially the fact that you made the distinction clear between change management and change control.
You’re talking about some really technical things here. Is this something that implementation partners necessarily bring up on their own? Like, how does this discussion start between an implementer and the customer?
Ken Foley
Yeah, well, I would say—system integrators’ primary focus obviously is getting you live on time and, hopefully, within budget, and making sure that the users understand how the system works. There’s a lot involved in the work at hand. You know, making sure they’re properly designing the system for the customer.
And, you know, properly getting it configured, making sure the data’s coming over correctly, the mapping’s correct. So my point there, Chris, is there’s so much when it comes to just getting the system live, right? So I can understand why what I’m talking about today doesn’t get addressed all the time, right?
And I’m maybe a little bit unique. I know there’s a lot of people out there like me though—my perspective isn’t just the implementation, but I understand, especially with a managed services background, and living with the customer after go-live and having to deal with the issues after go-live, I am more sensitive to kind of the operational aspects—what’s going to occur, what life’s going to look like post-go-live.
As a result, I have a tendency to have those types of conversations. And what we try to do here at RPI is involve managed services early on—the administrative types of activities that go on during implementation, I try to get a managed services person involved so that the customer gets to know them and gets comfortable, so that, you know, to be honest, they’d be more apt to sign us up after go-live to continue, or at least help them and extend it a little bit for them so that they’re supported.
We’ve had clients that leverage us for like a year after go-live. And then, at the end of that year, they were good. They didn’t need us necessarily for any of the proactive stuff that Infor would expect a client to take on. But they kept us on for more of the reactive stuff—like if they had a new business requirement and needed some development on it.
Chris Arey
I feel you. Yeah.
Ken Foley
They would come to us. It was more of an ad hoc thing rather than proactive monthly type of stuff, you know. But that’s kind of been our approach with that. So, you know, in essence—maybe not all system integrators, but they have the clients’ best wishes in mind, obviously, because they want the implementation to be successful, that is for sure.
But there’s the next step, the operational. So, I think Infor calls it ‘deliver to run.’ Deliver is your project, and run is moving on after go-live, right? And there’s a whole transition for that too, that has to take place, right?
Chris Arey
After go-live? Okay, yeah.
Ken Foley
There’s knowledge transfer, you know, because the project resource is not going to be there forever. They’re moving on to the next project, right? You have to have somebody in place that truly is going to be able to take the reins and run with it, right? We offer that as kind of a little bridge for them, to give them more time. If they’re really focused on the implementation, we help them along the way to learn about the operational approach to things.
And, again, they know their operations better than we ever would, right? They truly know what they have, how they handle change, right, in their organization and all that. I’ll, you know, kind of enable them—okay, this is how you can do it within the Infor system, and how that would fit into what you have for all your other stuff that you have.
Because it’s not just the Infor ERP that they have—they have desktops and other servers, other enterprise applications, and, you know, they already have IT infrastructure in place operationally. We just have to make sure that Infor can fold into that, you know, just seamlessly, really.
Chris Arey
Yeah. Really good stuff there, Ken. I appreciate your honesty, too. And this is what I think makes your perspective so valuable in a conversation like this: you’ve lived through enough of these implementations and seen the things that maybe are getting deprioritized that need to be a part of the project.
It’s like the plane-while-you’re-building-it-while-it’s-flying thing, all over again. It’s really good. And I also like the nod to the managed services too, because I had a question for you about this—is the recommendation here just to document these things? And it sounds like there’s a big administrative component that can be handled throughout the process through those managed services.
So really good, really good plug there too. Thank you. Let’s jump to your third and final bucket that you have prepared today from the operational standpoint, and that is governance, everybody’s favorite topic. What can you share?
Ken Foley
Yeah, sure. So, I probably—most of you have heard of SOD, or segregation of duties, too. That’s been called out. So Infor introduced a module, maybe a few years ago now. Time just flies for me—sometimes it feels like it was just a year ago. No, it was three years ago. Okay, so they have a module called GRC: governance, risk, and compliance.
All right. And what it does is it audits all your applications, landmark and non-landmark, and detects any segregation of duties violations or potential fraud based on how you got templates set up in your system. And I know Infor delivers out-of-the-box templates, so you can take a look at those. You may just go with them, you may want to tweak them, whatever, based on your organization.
We have to understand, too, that not all organizations have one person for every possible activity in the company, right? You may have people that have multiple hats. You have to account for that when you do your templates, because you don’t want a segregation-of-duties violation every time a valid action has occurred. And this also helps with streamlining user provisioning.
The reaction is compliant. It provides audit trails for all the activities. You know, like I said before, it works with everything. So, landmark applications and non-landmark, like WFM, XM, Birst, IDM, and so forth.
But what I learned, Chris, what I was trying to get straight in my head here at Infor Connect, they were introducing templates for landmark applications only, right? If you are just focused on FSM, HRT, payroll, anything, and I know MSCM is going to eventually be a landmark application, too.
They’re already delivering, and they will be delivering more templates, segregation of duties functionality, reporting functionality right within Landmark. You could actually probably start that now. You probably already have some aspects of it in your system. You just have to look for it.
I’m not sure if there was a toggle of some sort, but it should be in there. And there should be some templates, and I think they’re going to deliver more, but you can create your own from scratch too. So if you’re interested in that aspect, you could probably look on your tenant if you’re live already, or if you’re implementing again, if that’s who you are, then it’s there.
Take a look at it and see if it’s something you want to kind of address before you go live.
Chris Arey
You mentioned that a lot of these templates were announced or showcased at Infor Connect, is that right?
Ken Foley
Yes, yep. They were describing the solution itself and telling us about the difference between that and the GRC. Obviously, if you have the full suite of everything, including WFM, and you want to govern Birst, XM, all those products, then GRC may be the direction you want to take a look at, for sure.
Chris Arey
Okay. And I’ve heard you kind of describe this mindset that people need to adopt when they’re thinking about this stuff. And I believe you called it ‘think like a thief.’ Is that right? Can you tell me why? Where did that come from? What’s the story?
Ken Foley
Yeah. So I had a manager earlier in my career, and he told me that you need to think like a thief when it comes to looking at your security, right? So what could someone do in the system that’s possible, and commit fraud, right? In essence, right?
So, meaning, you know—he told me it’s usually going to be an inside job. It’s not going be somebody from somewhere, you know, across the world, that’s going go in and do something. It’s going be somebody who’s inside, right? And you get two types of people, all right?
So you’ve got somebody who’s going to discover that they can do too much in a system, right? Well, there’s a few—one person will never even look, right? Security by ignorance, as they say, right? They don’t care.
They’re just going do their job. They’re going to do what they’re told they’re supposed to be doing, and you’re fine. You’re safe there, right? Then you have the person who is, you know, going to go looking.
You know, they’re going to look and say, ‘ooh, I can do this and I can do that,’ and then they will try to get away with something. And then you have others that find it, right? They’re just as smart as the second group of people, but they come to you right away and tell you, you got a problem here—’I found this, so you may want to look into this.’
I run into all three, right? So ‘think like a thief’ is basically an advance on somebody finding something—test out all the scenarios you can think of to make sure there are no holes. So, as an example—I think I shared this with you at one point—can one user create a vendor and put their name and address on it?
Maybe even tie their bank account to it, right? Create an invoice for the vendor that they just created, for a thousand bucks, let’s say—keep it even, right? Run a cash requirement, run a payment cycle to create that $1,000 payment, right? And somehow get access to printing the check or processing the ACH so it has your account, right?
And then, when it’s all done, you go back to the vendor, you change the name back to whatever, to try to cover the trail. Now, you smart people out there know that there are audits you can run, too, on vendor records and stuff like that. But just, you know, bear with me—this has happened, right? I’ve seen it happen.
So, as an example, think like a thief, right? Come up with those types of scenarios.
That you have to guard yourself against. Now, segregation of duties helps a little bit, right? Obviously, because you’re going to have a template that says you cannot have somebody that can create a vendor and, you know, add the vendor to the system, release it so it’s active, right? And then also be able to create an invoice for that vendor and be able to pay that vendor and cut a check for that vendor or process a payment for that vendor.
And then change the vendor back, right? There are going be templates out there for that. And, you know, some people will say it’s such a pain—because then I have to go to this person to create the vendor, I know all the information, I should be able to add it’—that’s why, guys.
Chris Arey
Yeah, wow. This is very much security-related too, then, this governance piece. I can tell, by the way you’re giving these examples, that this is probably something you’ve encountered in your thirty-plus years. Is there anything you can share, without naming names, of something that maybe happened?
Ken Foley
Not so much that it happened. It was places where I worked, where it happened. I have not seen that at a client, because we’re usually pretty good about securing the systems, you know. But I do want to share, though, that recently I had a public sector client—they were very security focused, right?
Public sector, you know, especially in state-related agencies and all that, are very, very good about security. So I just want to share—they came to us with very hard but fair questions prior to go-live. They were thinking ahead about: how do I report on this? How do I know what roles were granted, what security classes are assigned to those roles, and what do those security classes give access to in the system, right?
How do I run a report that just gives me that, holistically, you know? So they’re very proactive there. Change control was a little bit different—they have a very formal change control process.
But I didn’t hear word one about it during the project, you know—formal policy and procedure in place, especially for third parties. We’re a third party, right? So they had to watch us perform the deployment to production—like, visually see us doing it—as part of their policy. So it would have been nice if we knew that kind of thing upfront.
Chaos hit post-go-live, and we had a bunch of changes we were, you know, submitting and all that. So they had, you know, requests for change—they have a change board, a governance board that they go through, that they have to present it to, right? And they didn’t know, at the time, what was involved with what had to get done in the system.
We had to be very involved in that, and sharing information about it. You know, so, anyway—that’s one example of it being good to plan ahead, so that we’re just on the same page. When you go to post-go-live, you want to be clicking already.
Chris Arey
You’ve mentioned, through these examples and stories, some of the consequences that can happen when organizations are not prioritizing these things. But I have to ask—maybe we can just spell it out clearly. What happens if a team decides this is not a priority until after we go live? Like, what does that look like?
Ken Foley
Yeah, so my rule of thumb is: the first three months are always tough to navigate, regardless of how well the implementation goes, so there is going to be a lot of support required.
So you’re consumed with dealing with that type of stuff, okay, on a brand-new system. Bank and interface file, for whatever reason, didn’t transmit. Payroll adjustments need to be made, but they have a question for us—okay, how would we properly do this type of scenario? Because it might not have come up ever, you know. In a first payroll run, they have to make sure that goes out right, right?
The operational stuff, you know, it’s very important. It gets pushed down on the priority list because you’re fighting those fires and it’s now production. So if you’re live, you must get stuff done. The business process has to move forward, right?
We’re going to document it. We will, but it’s going to be more retroactive, right, rather than proactive. If you plan ahead and you have things in place prior to going live, it’ll be second nature. And you know, especially when you’re fighting fires, you don’t need to be learning what’s the procedure for this and all that. You already know it, right? You don’t have to think twice about what has to get done as you’re fighting those fires.
Chris Arey
Yeah. It sounds like we’re acknowledging that this stuff does get pushed down, but it pays to prioritize it throughout the duration of the project, so that when you do get to go live, it’s going to lessen the load those first three months.
Well, Ken, this has been a delightful conversation, as always.
Ken Foley
Yeah, absolutely.
Chris Arey
You might recall, but before we wrap up, I always like to ask my guests what their actual takeaway is for the audience. I’d love to hear what you would like to impart to today’s listeners?
Ken Foley
Absolutely. Yep, yep. So think about what you do today in your current ERP—in terms of system administration, security, user provisioning, deprovisioning, segregation of duties, you know, all the stuff we talked about, SDLC, change control. So, as you go through your implementation, be proactive with questions and determine, at least at a high level, how you want things to look after you go live.
So that’s what I would do. You may not necessarily get to everything, but at least you have thought through it and have a plan.
Chris Arey
That’s what it all comes down to, right? Thank you, that’s awesome. For those of you listening in, if you have any questions, or want to learn more about how RPI can help you with thinking operationally for your next ERP project, let’s have a conversation.
You can contact us at podcast@rpic.com. Again, that’s podcast@rpic.com. This has been RPI Tech Connect. Until next time, folks, thank you so much.
Ken Foley
Thanks for having me, Chris. Appreciate it.
