Date: 15 August 2022
Implementing Enterprise Resource Planning (ERP) software is a major investment of time and resources, yet many projects don’t achieve the anticipated benefits. Allocating funds towards comprehensive business analysis is among the measures you should take, so the expected value flows from the project and makes a considerable effort worthwhile. If you don’t make a sufficient and well-targeted investment in business analysis, things can and often do go awry.
In my previous blog, we covered some of the things the BA is responsible for, including project scope, stakeholder liaison, and value prioritisation. What’s interesting, especially for those organisations that have an internal BA capability, is that this assistance is more effective if it comes from an independent, external BA. Let’s examine why.
But first, let’s look at what the BA DOESN’T do.
Just as important as a clear understanding of what a BA is responsible for (with some key points covered in the previous blog) is an appreciation of what we don’t do.
Top of the list is that we aren’t responsible for choosing a system (that’s usually a task for so-called ‘spec and select’ consultants or the business owner/s themselves). Our role isn’t implementation, either – instead, we analyse and advise. Which system? This isn’t as important a question as it may seem; like buying a new car, it is unlikely you’ll find a truly bad system. That said, some are more suitable than others – choosing SAP for a small business, even if it is Business One, is rarely a good idea. In fact, the choice of implementation partner generally has a greater impact on success than the selection of vendor.
A corollary is that the BA doesn’t need specific knowledge of any particular system or technology (although it doesn’t hurt, and during a BA career, we will get to grips with many); see ‘spec and select’ above. This is important and goes to the point I’ll cover below about independence, because it frees the BA to examine the true business needs of your organisation without ‘shoehorning’ those needs into the dimensions or features of any particular software system on the one hand. On the other, it also means the BA won’t draw inaccurate conclusions about your requirements.
We also don’t simply record requirements dictated by stakeholders, because there is routinely a discrepancy between ‘perceived’ requirements and actuals – our job is the extract sometimes conflicting perspectives from all interested parties. In other words, we must ‘be the consultant’ and sometimes tell our clients things they don’t necessarily wish to hear!
BAs, too, aren’t testers (in a following blog, I’ll detail the relationship between BAs and testers, because it is an interesting one), but we do work closely together, with requirements from the BA used in the development of test cases. And finally, our job isn’t about ‘nice to haves’, which can lead to expensive development for little return. It is about exposing the necessary features and functions which best meet your organisation’s business needs.
To a man with a hammer, everything looks like a nail
Knowing what the BA does and doesn’t do quite strongly implies why an external BA is better positioned to add value to an ERP implementation. While many, especially larger organisations have internal BA teams, they are not well-positioned to deliver insights and guidance on an ERP project. This is because they are too close to the organisation and quite often are Subject Matter Experts. This is an issue because the SME’s job is to deal with the details; the BA ERP advisor must be a generalist taking in the big picture across divisions, departments, and stakeholders. ERP is by nature cross-functional, so a cross-functional view is essential.
This is not to say internal BAs can’t contribute or shouldn’t contribute. They most certainly can – but if you are to achieve optimal value from business analysis, it is far more likely to result from a proven external consultant with no vested interests, political alignments, or preconceived ideas of how specific aspects of your business operate.
What are the most common problems encountered by the external BA?
The number one issue we encounter is that the external BA is engaged at the wrong time and that ‘wrong time’ is later than ideal. Getting a BA involved after the RFP is issued is too late; a lot of the value they should have added goes into creating the MFP. Another issue is if the BA expertise is inadequate or insufficiently broad selected. You need a BA across the entire project – and if a systems integrator or vendor provides functional consultants, these do not a BA make.
It is also important that where multiple BAs are working on the project, a hierarchy is established. If this isn’t the case, a situation may arise where there are ‘too many cooks in the kitchen’. This can convolute, confuse and delay. There should be a clear delineation of responsibilities – and that extends to what I call the ‘3 Amigos’ of any sound ERP project: Project management, BA and test.
In my next blog, we’ll look a little closer at the other two Amigos and examine BAs quality to assure your ERP by working closely with testers.
