Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Today we're hitting one of the biggest beasts in the BA world,
custom ERP implementations. If you've only ever worked on
package SAS apps, integrations, workflow, listen closely because
a custom ERP implementation is atotally different universe.
(00:23):
The analysis is deeper, the processes are messier, the
configuration options are limitless, and the consequences
of getting it wrong are massive.The Better Business Analysis
Institute presence, the Better Business analysis podcast with
Kingman Walsh. Welcome back to the Better
(00:47):
Business Analysis podcast. I'm Benjamin Walsh and today, as
I said, we're going to be talking about custom ERP
implementations. ER PS aren't just another
system. ER PS stand for enterprise
resource planning. And it's kind of like the
organization's nervous system. This is one of these behemoth
(01:08):
applications and if you touch itwrong, 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 ABA
should tackle a custom ERP implementation.
So let's get into it. So why are custom ER, PS in the
(01:32):
kind of next level complex category if you've never
experienced or used an ERP before?
Here's the blunt truth. Every process is connected to
five others, so there's no isolated change.
A tweak to maybe the procurementarea effects inventory,
inventory effects, finance, finance effects reporting,
(01:55):
reporting effects, governance. So there's this analysis web
you're, 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 micro
services or SAS applications andwe have middleware to join them
together, we we can just focus on one area or it's ERPSI guess
(02:16):
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, not because they're incompetent, but
because Erps force them to define how the business actually
runs, not how they think it runs.
(02:36):
And a side note here, if you've not experienced ERP, you would
have things like SAP, this Oracle ERP, them Dynamics came
from it. I worked in the vision back in
the day. They're like these big systems
that do all the modules, all thethings right.
And they're not sometimes built with modules, but they require
(02:58):
you to do customisation because you're genuinely an
organisations who's doing something complete complex.
So even manufacturing processes industries, even though they're,
you know, they follow the same steps in some ways, there's a
lot of configuration you need for your set up.
So you can't get away from configuration or customization.
That's the point of this podcast.
(03:19):
As opposed to a sales force 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 set of
mentation for maybe something that's like, I don't know, a
wood processing plant. OK, that would be an example.
Configuration in that example isas powerful as code.
(03:42):
So in custom Erps configuration can make or break the entire
solution. OK, so this is literally 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 BAS wheelhouse, by the way.
(04:03):
Developers can't rescue it, OK, because it just reads the, the
it's made so it can be so configurable that it can do
anything. And so you must do more process
analysis than any other type of project.
ERP isn't requirements first, it's process first, which
actually I would say is, is mostprojects, but you're building
(04:26):
how the organization works operationally and you're trying
to work with the, 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 a
doctorate level, a project for AB for ABA.
So if you've done ERP, everything else in terms of
complexity of analysis and configuration should be a lot
(04:50):
easier. So what do we do?
What's the right approach to tackling an ERP?
Well, there is a blueprint and I'm, I'm going to give you my
blueprint. You may have your own and that's
I'm going to lead you through it.
So step one is to understand theenterprise before you even touch
the ERP. You can't jump into a future
(05:10):
state design until you know the operation model, the value
change, the financial model, thecustomer flows, how the data
works, what the real bottlenecksare.
You have to do all that. You have to do that from a
current state and a future stateefficiency without the system
and without this, you know, the ERP becomes a Frankenstein of
(05:31):
assumptions and you get LED through each module individually
and you create a mess. Number 2 is to deep dive into
NTM processes. So Erps require these NTM
process modelling 100% one five at least not isolated functional
mapping. So just big it's you know, user
story mapping is is not a thing here.
(05:53):
The minimum journeys look like they're you know, there's some
standard ones. So there you might hear lead to
cash or lead to opportunity. Be sure to pay higher to retire
forecast to report that all you know rhymey make build to
deliver asset life cycle management, customer service and
(06:17):
you must met these. Let's say I said 5 is probably a
good idea, but level 33 processes here. 1 is the level 0
will be your high level value chain #2 are your core process
areas and number. Level 2 and 3 is D tub, steps,
rules, data and actors. You need all that OK, That's
(06:37):
where 50% of the real BA work happens.
That's really where adding the most value in this kind of doing
state here and in #3 you need todefine the solution scope via
the process gaps. So you're not defining solution
as any other project by what theuser wants, you're defining it
(07:00):
by gaps. Aim points control issues is a
big one. Data issues, compliance
requirements and process inconsistencies.
I guess ERP is about fixing the model and 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 of
(07:23):
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 3, 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,master data, rules, integrations
(07:48):
and reporting and financial controls.
This is not a business as usual requirements writing.
This is architectural level requirements writing.
OK #5 is to dive into the configuration requirements, and
this is where 90% of junior BAS would fall over.
(08:11):
ERP configuration requires mapping workflows to system
behaviour, 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 sales force
(08:32):
implementation, but usually they've got a process.
Thus, you might have to define yourself, and you must know how
the ERP 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
(08:56):
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 SeniorBA analysis number six is to
(09:16):
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.
(09:40):
I would suggest that a full ERP implementation might have like 5
BAS on it. OK, so this is the other thing I
I must note, this is not generally a job.
For one, BA #7 is cut over data migration and operational
readiness and and all the work, the hard work is still not done.
We get this wrong. The whole project fails.
(10:02):
BA probably a lead. BA must lead master data
cleansing given the data in the right format, mapping old data
to new structures, maybe helpingwith a cut out of the playbook
right and creating that businessreadiness.
You might work with a change manager on that role based
training content and and processbased training so they know what
(10:26):
they're doing per role and UAT scenarios tied to those real
process flows. OK, so that's process based
training and ERP go live successes.
They, they, they succeed or theydie on those tasks, even if
you've done everything else perfectly, right?
These are really, really important.
So a lot of people scoop on thisbecause time runs out and what
(10:49):
BAS must do differently on an ERP, 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.
(11:10):
ERPS hate bespoke and 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 leave that, not someone
else. That's BA.
Own the process to system traceability.
(11:30):
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 decisions break finance, the project is kind of big.
So if you're ABA stepping into the world of custom ERP
(11:53):
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.