Hi Björn,

The reason for this discussion is NOT necessarily to propose a specific classification of analysts but because this classification already exists yet it is very ambiguous. In most large organizations and large projects the division of tasks is much more defined then on a smaller project where the analyst does everything. Sole practitioners may be very used to doing everything, from analysis the business model to creating technical specifications; however most analysts do not have the skills, experience, and competencies to do it all.

I also see junior analysts who are very confused (for a good reason) because when they interview for different positions they are turned down for various reasons. One employer may tell the candidate applying for the "Business Analyst" position: "You don't have enough business process modeling skills?” another employer may tell the candidate applying for a different "Business Analyst" positions: "You don't have enough system modeling skills?".

The poor junior analyst is puzzled and confused: "Do I need to know everything in order to start my career as a Business Analyst?". The answer is NO, you don't need to know everything? That would be impossible and we would have nobody new joining our profession.

What needs to happen is for employers and recruiters to Cleary define the "roles" expected of the analysis position and define the key tasks expected of that job. For example, if the key goal of the position is to analyses, document, and model business processes within the organization then I would give the position the title of "Business Process Analyst/Modeler". If the mail goal is to gather, analyze, and document business requirements then I would use the title of "Requirements Analyst/Engineer". If the goal is to create functional and systems specifications then I would use "Systems Analyst" or maybe "IT Business Analyst".

There are very few instances for which I would advocate using the generic "Business Analyst" term.

Hope this helps answer your question as to why this discussion. ;-)

Best regards,
- Adrian

I don't think that I'm implying that there is a hierarchy of knowledge.  I'm just suggesting the reality and trying to clarify the labels already in use for analysts.  Let me try to explain by way of example:

I the "old times" the programmer did everything.  They met with the user, did the analysis & design, coded, tested, and delivered to the user.  With the commercialization of software development it was clear that, in order to be able to achieve economies of scale and find enough qualified resources, most companies began to specialize these roles.  That's where we got the Analysis, Development, & QA professionals.  Even when I first got my first job, my title was programmer/analyst and I did everything: requirements gathering, analysis & design, coding, testing, and delivered the software to the client.  As the company/department grew there was a natural evolution of the responsibilities where we had the business analysts and then the programmer/analysts (developers).

Maybe this idea is a bit ahead of its time, but the same thing is happening to the role of the business analysts.  In order to achieve economies of scale the role of the analyst is more granular (at least at larger corporations) and there you will see clear distinctions between a business process analyst, IT business analyst, systems analyst, etc.

That is not to say that there are no business analysis practitioners whose role is to cover all areas of analysis.  This is very common in the big 5 and management consulting firms where the consultant works on a variety of projects and tasks and therefore they are expected to be able to perform all those roles.

And yes, in those companies they do have junior Business Analysts.  Pretty much anybody they hire straight out of college starts as an junior/associate consultant (business analyst).

- Adrian