One of the most important roles in a data warehousing project is the business analyst. However on most projects the role can involve several different roles. In addition, the project might require then to fill multiple roles.
The first and most common role is that of defining business requirements. So let us call this function business requirements analysis. In this role the job of the data analyst to discover from the business their requirements for the project. These requirement can be documented in various ways. Often the requirement can be expressed in the form of questions the business has. Another way the requirement can be expressed is in the form of report requirements. In each case we are not looking at the business processes, only at questions the business has or the reports the business wants.
Another role is that of business analysis. This role is more challenging because the analyst must understand the business and the challenges the business is facing. Based on this understanding, the challenge of the analyst is to come up with ideas about how better information can help the business perform at a higher level. Take as example a retailer who captures buying patterns of shoppers based on the cash register record. The analyst might suggest to focus on a segment of purchases and analyze the profitability of that shopping basket. Another way of analyzing the buying patterns is to look at the customer as opposed to the basket. The customer buying patterns can be analysed often through loyalty card data. A good analyst will look at the actual processes in the store and ask different questions than the retailer might ask to divine business intelligence.
The third activity as opposed to role is one of design. The result of most analysis is a design to meet requirements. I have found that most analysts rushed to solution and design far to fast. Based on the data that is available the analysts quickly comes up with reports that can present the data in new ways. However if we avoid the steps of understanding the business problem, we will rush to a report based on the data we have as opposed to a response to a business problem. Most analysts will rush to solution and design because of the discomfort of dealing with uncertainty and admitting to a lack of understanding of the business problem and process.
The business analyst is caught in the middle between the business and IT folks. The role is to create a bridge and understand the issues on both sides of the chasm. I do not think we appreciate how difficult the role can be and do not give them support they need in dealing with the complex issues of data warehousing project hoping to deliver business intelligence.
Great comment about not isolating the business from the developers. I agree that being part of the team with the business is very important. As you say, this teamwork is especailly true when we are using agile techniques.
My comments did not mean to separate the developers from the business. The team really needs to work together to create the solution. The whole team really needs to focus on understanding the business questions before rushing to solution.
I have more concern about the analyst rushing to solutions before understanding the business issues.
We have found that many business analysts are designing report formats long before the business questions are really understood.
I would be interested in other people’s experiences.
Placing analysts between the client and IT, makes IT (assume development) an order taker, with no true engagement guaranteed in meeting the needs of the client. They simply meet the needs of the analyst.
Agile development tends to bridge this gap in a different way by connecting the service delivery (technology) with the client, and iteratively defining the requirement through a shared understanding expressed as parts of a solution – a language they both must understand if acceptance is to be achieved.
The role of the analyst is not eliminated, but rather made part of the team as opposed to a bridge.
The more the construction team understands the domain, the better the solution. Emphasis on this only being achieved through the ‘analyst’ who might not know the solution technology might make ‘him’ more effective but does not guarantee requirements are met…
Thanks for the post.
I think that the more the analyst understands the business the more effective he will be. However if he becomes too much of an expert, he then does not have to ask the business their requirements because he already knows the answer. The analyst walks a fine line between understanding the business but still reponding to the clients requirements.
Knowing the latest best practices can sure help. I have just done some research on best practices and found some neat stuff that I will write about. The most mature organizations claim to be able to produce results very rapidly.
Of course without a good analyst and a business that know what they want, rapid BI can be a real challenge.
Good additions to the list. I wrote a post a while ago about rushing to solution on the part of the analyst and the business. See
Nice post. Just a couple of points to add to your list.
1) Ability to drill down and abstract as the need and audience is.
2) Also, the analyst has to be adept at understanding of business to help prioritize the requirements.
3) Able to focus on business needs (and quench the urge for proposing a solution!)
4) Stay on top of industry best practices (and appreciate technical capability) – this really brings in the highest added value to a group.