The Brutal Truth: How Business Analysts Should Approach a Custom ERP Implementation

Speaker A: Today we're hitting one of the biggest beasts in the BA world. Custom ERP implementations. If you've only ever worked on package SaaS, apps, integrations, workflow, listen closely because a uh, custom ERP implementation is a totally different universe. The analysis is deeper, uh, the processes are messier, the configuration options are limitless and the consequences of getting it wrong are massive. The Better Business Analysis Institute presents the Better Business Analysis Podcast with Benjamin Walsh. Welcome back to the Better Business Analysis Podcast. I'm Benjamin Walsh and today, as I said, we're going to be talking about custom ERP implementations. ERPs aren't just another system. Erps stand for enterprise resource planning and it's kind of like the organization's nervous system. This is one of these behemoth applications and if you touch it wrong, you paralyze something important just like your nerves. So today we're going to be walking through the real approach, the non nonsense practical blueprint for how a BA should tackle a custom ERP implementation. So let's get into it. So why are uh, custom erps in the kind of next level complex category if you've never experienced or used an ERP uh before? Here's the blunt truth. Every process is connected to five others. So there is no isolated change. Uh, a tweak to maybe the procurement area affects inventory, inventory affects finance, finance affects uh, reporting, reporting affects governance. So there's this analysis web you're kind of stuck in, right? There's no one line, there's no one area. So when we have split our applications out using microservices or SaaS applications and we have middleware to join them together, um, we can just focus on one area or ERPs, I guess you could say it's a benefit but a cost is that they're tightly coupled so the business really knows what they really need. Uh, not because they're incompetent, but because ERPs force them to define how the business actually runs, not how they think it runs. And a side note here, um, if you've not experienced erp, you would have things like SAP. Uh, there's Oracle, erp them, um, Dynamics came from it. Ah, I worked in the vision, um, back in the day. They're like these big systems that do all the modules, all the things right and they're not sometimes built with modules but they require you to do customization because you're generally an organization who's doing something complex. So even manufacturing, um, processes, um, industries, even though they're know they follow the same steps in some ways, uh, There's a lot of configuration you need for your setup, so you can't get away from configuration or customization. That's the point of this podcast, as opposed to a Salesforce implementation where you've got IP built in. And there is, there is IP and some ERPs, but this particular example I'm thinking of as a SAS implementation for maybe something uh, that's like a, uh, I don't know, a wood processing plant. Okay, that would be an example. Configuration in that example is as powerful as code. So in custom ERPs, ah, configuration can make or break the entire solution. Okay, so this is literally um, saying that your GL has these options or that item code 197 points to 197 over here. If the BA doesn't get the config right, which is generally in the BA's wheelhouse by the way, developers can't rescue it, okay, because it just reads the, the it's made so it can be so configurable that it can do anything. Uh, and so you must do more process analysis than any other type of project. Um, ERP isn't requirements first, it's process first, which actually I would say is, is most projects, um, but you're building how the organization works operationally and you're trying to work with the constraints of the ERP and not doing anything additional. But there's still a whole lot of work you need to do. That is why ERP is almost like doctorate level project for a B, for a ba. So if you've done erp, everything else, um, in terms of complexity of analysis and configuration should uh, be a lot easier. So what do we do? What's the right approach to tackling an erp? Uh, well there is a blueprint, um, and I'm going to give you my blueprint. Um, you may have your own and that's, I'm gonna lead you through it. So step one is to understand the enterprise before you even touch the uh, erp. You can't jump into a future state design until you know the operation model, the value change, the financial model, the customer flows, how the data works, what the real bottlenecks are. Ah, you have to do all that. You have to do that from a current state and a future state efficiency without the system and without this, you know, the ERP becomes a Frankenstein of assumptions and you get led through each model individually and you create a mess. Number two is to deep dive into NTM processes. So ERPs require these endian, uh, process modeling 100% 1 to 5 at least not isolated functional mapping. So just be, it's you know, user story mapping is not a thing here. The minimum journeys look like there, you know there's some um, standard ones. So there you might hear lead to cash or lead to opportunity. Procure to pay, uh, hire to retire, uh, forecast to report. They all you know, rhymey make um, build to deliver, um, asset life cycle management, customer service. And you must map these, uh, I said five is probably a good idea but level three, uh, three processes here. One is the level zero will be your high level value chain. Number two are your core process areas. And number level two and three is detailed steps, rules, data and actors. You need all that, okay. And that's where 50% of the real uh BA work happens. That's really, we're adding the most value in this kind of doing state here. And in number three you need to define the solution scope via the process gaps. So you're not defining solution as any other project by what the user wants, you're defining it by gaps. AIM points, control issues is a big one. Data issues, compliance requirements and process um, inconsistencies. I guess ERP is about fixing the model and not replacing today. So this is usually companies that put in a big erp. That is because they're in a really regulated area and usually a conservative kind uh of marketplace and they have some real tight compliance. Like your tax department is a good example of one that I've had some involvement in. After you've done step three which is you know that gap analysis, you then define the high level requirements, epic level requirements which must map to your process steps, procedures, uh, master data, rules integrations and reporting and financial controls. This is not a business as usual requirements writing, this is architectural level requirements writing. Okay. Number five is to dive into the configuration requirements. And this is where 90% of junior BAS would over ERP. Configuration requires mapping workflows to system behavior, mapping business rules to configuration objects, mapping organization structure to system hierarchy, mapping roles to permissions, mapping data models to real master data. And yes you do some of these things in like a Salesforce implementation, but usually they've got a process. Uh, thus you might have to define yourself and you must know how the erp, ah wants the business to work. That's a weird one, right? The ERP wants the business to work. You're accepting some kind of ip, some kind of constraint. That's the whole point. Instead of building it yourself, where can you flex where you should not flex? What choices will break downstream processes and what choices will Break Finance, which is generally a no, no. This is where you earn the title of senior ba. If you get through this and do this, this is like on the senior ba. Now number six is to define wrappers around the erp. Right? The custom bits and custom ERP implementations. There will always be extensions, custom modules, custom workflows, integrations, API layers, data transformations, and you have to define these in details and validate them against the core processes. So this is a lot of work. I would suggest that a full ERP implementation might have like 5 BAS on it. Okay, so this is the other thing I must m. Note. This is not generally a job for one ba. Number seven is cut over data migration and operational readiness. And, and all the work, hard work is still not done. If you get this wrong, the whole project fails. Um, um, B.A. probably a lead. B.A. must lead master Data Cleansing. Getting the data in the right format, mapping old data to new structures, uh, maybe helping with a cutover playbook. Right. And creating that, uh, business readiness. You might work with a change manager on that. Role based training. Content and process based training. So they know what they're doing per role and UAT scenarios tied to those real process flows. Okay, so that's process, uh, based training and ERP go live successes. They, they, they succeed or they die on those tasks. Even if you've done everything else perfectly right, these are really, really important. So a lot of people scoop on this because time runs out and what bas must do differently on an erp, uh, right, as opposed to other projects. And these are different. We've done our steps and now what we must think about from a mindset point of view is to be harder on process owners. You can't accept this is how we've always done it. Push the organization towards standardization. ERPs hate, um, bespoke. Bespoke means, you know, pain, delays, costs, bugs, technical debt. Treat data as a, you know, first class citizen. Every process relies on data discipline. You must lead that, not someone else. That's BA own, um, the process to system traceability. You're the transaction layer, the trans, the translation layer as well. No one else is going to do it. And you must protect the financial integrity of the system. ERP is ultimately a financial system. That's where it came from. If bas, uh, decisions break finance, the project is kind of dead. So if you're a BA stepping into the world of custom ERP implementations, understand this. It's hard, it's complex. You'll feel overwhelmed. Right? But it's also the project that makes your career if you do erp well, you can do anything. Thanks for listening and I'll spot you next week. Sa.