The older I get, the more I appreciate the specificity of language. For years, the skills of the business analyst have been part of my professional workbench. More recently, I accepted the challenge of teaching a course in business analysis for the University of Washington Professional and Continuing Education program. This brought me in contact with a plethora of new tools and techniques for business analysis. It also forced me to sharpen my skill and understanding of those I had been using for years. Imagine my surprise when very late in this process I discovered that I had been using the word analysis incorrectly for so many years.
Strictly speaking, I had not been using the word incorrectly so much as I had blurred the edges of what it really means. I had been using analysis as a synonym for close examination or scrutiny, which is consistent with what Business Analysis is. The discipline of Business Analysis consists of the tasks and techniques that lead people to understand and document how the policies and procedures of a business organization function. Clearly analysis involves such close investigation.
In reality, though, the word analysis is only part of that investigative process. Analysis is the breaking apart of a process, object, or chemical compound into its constituent elements. Equally important to this investigation is the opposite of analysis, synthesis, which is the construction of a process, object or compound from constituent elements. What was learned from analysis must then be synthesized in order to be useful. In essence, the entire discipline is inappropriately named.
We all know that even suggesting that Business Analysis be renamed to a more linguistically correct designation is an intellectual form of spitting into the wind, so I shall not waste my time attempting to do so. Nevertheless, the insight that I gained from the recognition will be useful to me both on the job and in the classroom. The process of examining this insight was itself a small example of analysis and synthesis.
Abstractions such as this abound in our discipline. One of the more profound “abstraction sets” I encountered during my recent academic expedition had to do with the concept of process. A process is a series of steps that, when executed in a particular order, produces a specific result. The preponderance of the effort in Business Analysis examines the workings of and reasoning behind business processes. For our purposes here, consider this business process – the process that is the focal point of our workbench full of tools and techniques – to be our A-level process.
However, in order to apply these tools and techniques to this A-level process, a group of people must step through an organized series of steps. This organized series of steps is also a process, but it is not the process being examined. Rather, it is the process that is performing the examination. This is our B-level process and while it does not resemble the A-level process, the A-level process may have influenced the choice of steps and their order. This is the process that the business analyst facilitates or manages.
Most A-level processes are in some way or another unique depending on the process, the industry, and the specific business rules of the company. A supply chain or product development process within a specific industry (and even for a specific product) may share many similarities, but will undoubtedly vary from company to company. The same is true of the B-level process. The design of the B-level process will also be unique depending on the nature of the project, the process being examined, and the participants. B-level processes may also share similarities, but the subtleties that make each unique are even more pronounced, particularly due to the human elements introduced by the participants. They may represent different departments, viewpoints, or values and all of these differences while important to the final product, make alignment and consensus challenging.
The experienced business analyst or facilitator takes the design of this B-level process very seriously, and typically employs a C-level process to design the custom B-level process. It is at the C-level that very little variation from instance to instance exists. The facilitator will employ essentially the same steps each time, but because each step results in a different answer set, the design of the B-level process will vary from instance to instance. The C-level process analyzes the needs of the A-level process along with those of the participants and synthesizes the B-level process from the analysis output.
For fun, let us add on one more layer of abstraction to this synthesis. This view of business analysis as three levels of process seems to function almost in the manner of sentence grammar. The C-Level functions largely (although not precisely) as the subject, articulating as it does the attributes of the activity (e.g., purpose, stakeholders, constraints) in order to design the B-Level process. The B-Level functions as the verb, performing the action on the A-Level (the object).
What emerges is a high-level model of the business analysis process. This will make it easier to teach the next time around. More important, it gives me a new paradigm for managing my own efforts in the field. Having modeled the three process layers formalizes what I have been doing for years into a more consistent set of steps and options.
As for renaming the discipline itself, I plan to stick to the decision I voiced above. Nevertheless, I could not help engaging in a quick mental search for a more fitting name. About the best I could do was Business Science, but that implied a level of precision not in evidence. I suppose that I will need to be content with the imperfect designation and concentrate on perfection in the process.
Does your organization manage its C-level processes? Can you think of a better name for Business Analysis?