AJC ERP System Selection: Define Future State Requirements

Andrea Jones (host) explains the first of five high-level steps in an ERP system selection: defining future-state requirements. She recommends mapping current processes (order-to-cash, procure-to-pay, record-to-report), forecasting scale (transactions, locations, international expansion), identifying integrations and unique needs (e.g., ACH billing, dashboards), and iterating through in-person or virtual workshops to produce a prioritized requirements list that drives vendor selection.
Chapters
Hi, I'm Andrea Jones and today I want to talk about the first of five high level steps in our system selection process. Primarily this is used for erp and that is the system of record I'm going to use in this example. But in general you can use it for really any system selection. So the first major step is to define your future state requirements. That is all the things you know you're going to need the system to do as you continue to grow and expand for however long into the future you can forecast. Often ERP systems are only changed once every 15 plus years. A lot of times companies really want it to be plus. So you want to make sure it can handle the volume of transactions, the size of your organization, a number of locations, perhaps any different different countries you're planning to expand into those types of things, integrations with different systems like a front end E commerce. So specifically in ERP there's three major process flows we like to map to get us to those future state requirements. And we typically start with what you're doing today. It's a great way to get the team kind of thinking on these terms and seeing what is different about what they do than what other people might do. Sometimes you've been working in a system so long that it's hard to imagine anything else and you think everybody must do it this way, right? So the three are order to cash, procure to pay and record to report. So order to cash is basically how do your customers order from you? Is it all via, you know, salespeople entering orders? Do they enter into the system? Are there contracts that they have to sign? Do people place orders electronically on an E commerce engine or in some other fashion? Is it, you know, again a contract depletion? Is it automatic sending things out to meet fulfillment POS or whatever it is, however they order from you start there and let's figure out all those ways because their information has to get into the system and truly if they're new customers, that information has to get there. Do you have a CRM, all that type of thing? And then as you go through fulfilling those orders, how do you schedule? If you're doing some sort of production or distribution, how do you fulfill that, how do you ship it or if it's a service, how do you staff and deliver and how do you track that labor, how's that put into the invoice, how do you invoice and how do you collect the cash or the money on the other end? Are there multiple channels in which you allow people to Pay, whether it's credit card or cash only or check or, you know, a multiple of ways. So basically order all the way to getting that money into your bank account. Okay. And then procure to pay is just kind of what it sounds like. This is often a big deal with companies that hold inventory. So they're buying certain things, they're holding onto them, so they have to sort them and put them into warehouse locations, and then they're pulling them, pick, packing and shipping them and sending them off to customers. You know, that goes along into the order to pay or order to cash. But how did they receive those things and how do they pay their suppliers? Possibly in there, some sort of supplier assessment that you want to maintain or a quality level that you need to maintain. It could be quality in order to cash, too. Okay. So that's kind of your operational side and some of the finance. The rest of it is record to report. As I said in our overview, a lot of reasons people want to put in a new ERP system is they need better financial data, more timely data. They don't want to have have to spit out a bunch of stuff into CSV files and manipulate it in Excel or put it in templates. That's just causing all kinds of disruptions. So what kind of information do you want to have at your fingertips, especially as you grow, Whether it's, you know, sales channels and what locations are doing better or what products are doing better, or what the margins are, labor margins and gross profit, gross revenue, all those different things, like what are the info, what's the information you need, and how do you make sure that it's in the system, in your ability to report on it and to report on it timely. And oftentimes you might have to integrate something like maybe a Power BI or some sort of dashboard. But basically, as you go through this for how you're doing it today, and then you turn your thoughts to, let's see how we could do it better in the future that will drive the requirements gathering. And there's a huge list of requirements. We have a pretty good subset for what most people need. There's going to be some specific things that your company will need that maybe others don't like. I talked to somebody recently who likes to automatically invoice via ACH instead of credit card pulling every month. An ACH debit happens automatically every month, and not all systems can handle that. So, you know, there's different things like that, or maybe there's different pricing that different contracts will allow for. And so you need to make sure the system can handle that. And we will look at of your whole requirements list what's super critical and what might be unique to you. And that is what drives, you know, the next step, which is to identify possible systems and vendors that could be a fit. One small caveat here with the whole define requirements is doing a technology map. I'm going to do a separate video on that because that could be helpful. A technology landscape map could be helpful always, but looking at all the different software and different systems you're using today could be a good way to understand what you're using it for, what's really needed, where there might be redundancies and what might be missing, which will help again fill in all those gaps in the requirements. One last thing is this isn't all handled in three days worth of in person mapping, although a lot of it is. And that's typically what we do. We can do it virtually too, but it's kind of nice to do this in person if possible. There'll always be some more things, so we'll be shoring that up and talking to people, seeing demos and following up for a few weeks at least to really get a comprehensive list and then call it down to those real critical requirements that we'll go look at in the next step. Thanks so much for watching.










