I always found the term "Business Analysis" a bit misleading. It is used for gathering system requirements - a technology role - while for me it resonates more the analysis of the business for business improvement - a business role.
When I moved from the Netherlands to Sydney, I needed to get used to different terminology even though IT is globally pretty much in English. But some terms are different and a term or a word comes with an interpretation of its meaning. The terms business analysis and Business Analyst gave me a bit to think.
Business analysis is, as the word says, the activity of analysing the business. But what aspect or dimension of the business are you analysing and for what purpose?
The most common interpretation in the context of IT is to look at the business and find out what IT needs they have. In the majority of the cases it comes down to identifying the requirements for the IT needs. We call these business requirements. I prefer the term system requirements since they address the requirements of the business for a specific system.
However, when I first ran into the term, my interpretation was a bit different. Business analysis can also be defined as analysing the business processes in order to see what can be improved, regardless whether this requires any automation or not. Much of the tool set for the first type of analysis can be used for this type as well. But you come from a different angle and have a broader scope. Let's call this business process analysis, though a more generic term like business consultancy might be better.
And finally, you can analyse your business for more strategic purposes. For example, if you produce and sell shoes, an analysis of your business could come to the conclusion to stop producing the shoes but focus on (re)selling shoes only. Let's call this strategic analysis.
From IT management perspective, we are usually more or less involved in all three types of business analysis. The first type is commonly our responsibility while our role in the third one is often absent. How much IT is involved in business process analysis and strategic analysis usually depends on how much "i" is there in IT.
With the "i", I mean the information part of IT. How much does the organisation see the IT department as only a tool provider (the "t" in IT) or how much does it see the department as driving the way information processes are organised? Do you have a CIO, a CTO or only an IT manager?
System requirements analysis is one of the first steps to be taken when an organisation considers implementing a new system or enhancing an existing system. It is the most critical step and it is surprising to see how often it is skipped or how much it is underrated. I had a case at hand when we were writing a business case for a new project and I added the phase for business requirements analysis. The business owner was surprised that this was all needed. She already had provided us with a single page containing 15 bullet points and wondered why we could not get a vendor starting straight away with the build phase. The requirements phase took in the end over 9 months of effort and the whole project took 2 years.
The key problem with system requirements in the form as mentioned is that it is not sufficient for a programmer to start programming. Requirements are only sentences in plain english that specify what the system should do. It is not a design of a system and a system design phase should be performed as well. You need logical data models, information architectures, page/screen designs, transition diagrams, etc. But I found that not all Business Analysts are well equipped to perform all these tasks. Even if they have learned the modeling technique, experience with building and using complete information systems is necessary to come to good results. In some cases Architects can take over this role, but the risk is there that they have had insufficient interaction with the actual business and their needs. The end result in terms of usability might just be a bit too much as techies see it.
Though system requirements analysis remains a challenging task, it can only work well if it is done following a business process analysis phase. The need for a new or enhanced system does not come out of the blue. Even if it would only be to make some user interface improvements, you can always point at some business benefits. For example, people make less mistakes or can work faster. You want the system because you want to improve or change your business operations. It is therefore important to take a holistic approach and model and design your business and only as part of that see what IT needs you have. If you skip this and just start asking for a new system, you run the risk that the system is based upon the old business processes, that you do not gain all the benefits of the new system and that the new system becomes an impediment for change. Incorporating business process analysis into the project is what I mean with putting the "i" in IT. You look at the information flow and the information processing needs in the context of the (improved) business operations.
Larger organisations have this usually covered. They have a CIO whose role goes beyond just providing tools. They have business process analysts that assist with business improvement initiatives. Because size comes with complexity, improving the business with IT solutions remains a challenge and just having some people in place does not solve all problems. As we read everywhere, becoming a strategic partner and to participate in strategic analysis is for example an ongoing challenge.
Smaller and mid-size organisations too often struggle with these concepts. On the one hand all this analysis work costs money. On the other hand insight in the concepts and the relevance of this, is too often missing making IT more expensive as it should be or less beneficial as it could be. This is a petty because these analysis phases are driving more the success of IT implementations than the subsequent technical work. When you find that the project is going bad in the technical phases, there is usually much you can salvage. But if you have selected the wrong system or build it for the wrong business processes, you might need to throw it all away and restart from scratch.
Too often, IT is asked for a tool without a clear analysis of the actual information processing needs. This should be done through an holistic analysis of the business process and associated redesign if the new tool is going to bring all the intended benefits. We too often forget the "i" in IT. IT is not just an engineering discipline, it is about effective processing of information.
