Date: 18 July 2022
A recent chat with the owner of a medium-sized business turned up a valuable nugget: ‘You can spend a lot of money developing software which adds no value’, he said. And he’s absolutely right.
Software projects are expensive. Enterprise software projects, like ERP, CRM, Business Intelligence, etc., are expensive and incredibly difficult. Despite anything the vendor or system integrator might tell you, there are no cheap or easy options. And if you’re moved towards customising your ERP, it is entirely possible that you could spend a lot of money developing software that adds no value.
If that sounds like a really bad idea (it is objectively a really bad idea!), there’s good news. Avoiding this counterproductive, costly, and sometimes destructive practice depends on the sound contribution of a good business analyst.
But here’s the thing. The role of the Business Analyst (BA) in any enterprise software project isn’t, it’s sad to say, always clear. And that’s why BAs are often brought in far later than they should be, often after the development of the aforementioned boondoggle software.
Firstly: What does the BA actually do?
While some (or even most) imagine the BA involves themselves with process examination and design, there’s quite a lot more to it; there are in fact, three major ways our profession adds value to an ERP project. In addition, of course, to process examination and design.
1. Scoping the project
You must know the problem very well first before you have any chance of knowing the solution. The BA identifies the business need for a change by performing an Enterprise Analysis as part of the project charter or business case owned by the project/programme manager.
Therefore, the BA should be involved BEFORE you even decide on any particular ERP vendor or solution. The BA will help scope the project and the business requirements accurately – if your BA is being brought in ‘ex-post (this) facto’, you’re putting the cart in front of the horse. These requirements form the critical basis of any tender document: RFI, RFP, etc.
And if you’ve decided on an ERP before the BA got involved? It may be the case that you don’t need an ERP at all. If so, that’s what a good BA will tell you.
2. A meeting of minds
Then, a second further crucial function is stakeholder liaison. That bit above about scoping the project? Among the things that make ERP projects hard is that it’s a bit like herding cats.
With multiple stakeholders with (often competing) views and expectations, the BA draws out and confirms requirements from each group and works towards achieving consensus and overall scope. This culminates in presenting clear and accurate requirements to the project leaders and negotiating sign-off on an agreed plan.
3. Prioritising value
If it is decided that ERP is the way forward, the BA will help identify the Unique Selling Points of your organisation. Sometimes it’s not what you do, but how you do it. In other cases, what you do will be the differentiator.
This is a crucial piece that directly comes back to my opening anecdote. If the focus falls on the wrong things – that is, those aspects of the business which absolutely can be bog-standard – you don’t want to waste a single minute customising or doing anything special with the software. Leave it to the built-in best practice in the selected ERP system.
For example, in marketing, it is rarely the process that is special. Instead, it is the approach and ingenuity of the marketers – so don’t customise the marketing processes. If you have a unique approach to distribution, say, getting food out exceptionally fast, then that’s where customisation could add value.
Recently, my colleague Linda Street made a case for testers being involved in your ERP project from the get-go (read her article here). It’s the same for BAs. We will always add the most value when we get involved upfront; as for testers, the value we can add diminishes as the project rolls out because we find ourselves ‘catching up’. With so much at stake with any enterprise software project – and especially ERP – redoing anything is counterproductive and expensive. With the help of a BA, getting it right the first time is far more likely.
In the next blog, I’ll go over the differences between internal and independent BAs and examine some of what happens when there is insufficient investment in business analysis.
