Adrian,
First off thank you for your kind words on my article on www.itweb.co.za titled Going beyond Training”.
I often get asked by my customers what are the roles of all these titles. The way I answer them is the title in not relevant, because it will vary from company to company. The thing that needs to be looked at is the deliverables the role produces. If we look at any business improvement project, be it through process change or new or changed systems, there are three distinct phases.
The business understanding phase, “the what”. A certain set of skills is needed by the analyst to elicit and document “what” the business does. This will be the current state or as it is often called the “as is”. I find it fascinating that we create different roles based on the solution, when we will not know this before the “as is’ is complete. A good analyst will produce the correct documentationregardless of title. Now the decision on the solution can be made. One of three options is available,
1 Alter the manual processes (business rules, resources, queuing etc)
2 Automate the process or change existing automated processes
3 A combination of altered manual or automated process.
Why is it we have different titles options one and two.
The irony is that most improvement project in organisations today will be the hybrid option three.
The same documentation is needed for all three options.
Any organisation should be looking more at what is required to be produced, rather than the title of the person. If we understand that we can call the role anything, but we know what will be the result of this persons efforts should be.
That output moves into the next stage of the project, developing of the solution. This will require another set of skills from the analyst. But again we need to look at it from a results focus. The deliverable from this stage is the future state (To Be).
The final stage is the “how”. We have a business solution which requires a change to the way business is done, manual processes and automated process will need to be implemented.
How the process will be automated requires another set of deliverable, such as screen layouts, Use Cases, storyboards, data definitions, training plan etc.
But one theme runs through all of this the ability to elicit information from the business and document it in a manner that is understood by the teams down stream. So the analysis function will only succeed if the deliverable is clearly defined and understood by the analyst, and the teams down stream from the analyst.
The title debate is symptom of a greater problem in most organisations. The person involved in one phase has no idea what the person in the next phase need from them. I have heard MANY systems Analysts say the documentation produced by the business analyst is useless to them, and they start from scratch with their own analysis. If we look at the cradle to grave, and define what is needed during the entire analysis life cycle, then allocate the elicitation of a contextual sub set to each of the titles involved then we know we will be able to smoothly make the transition from one title to the next. In this way the title debate goes away and we get a full set of documentation to complete the analysis process
This was one of the reasons I wrote the book “Aligning Business Analysis, Assessing Business Analysis from a Results Focus” I busy with several clients in what I term “Business Analysis Improvement Project”. These are based on what I have said above and what is in the book.
As observed on here already there is huge overlap in what the various analysis roles, I do think the analysis role is going to break up into a career path based on the sphere of involvement. i.e. Task based, Project based, Enterprise based, and Strategy based. This will be facilitated by the increase in the understanding of the business. In other words to be an analyst who is strategically involved you must have gained a through understanding of the business across the entire horizontal. This knowledge is quite unique as most execs will have got there through one of the vertical silos.
Robin