Business Process Analysis

Often times a Software architect is called to fill in a role that does not fit his strengths. This could be driven by a number of reasons. I list a few on account of which I have ended up having to sharpen my business process analysis skills. I am sure you can add to this list.

1. The business analyst walked out in a huff/to new pastures at a critical time and someone had to fill in the spot.
2. You wanted to learn and experience something new and your supervisor knew of a vacant position that could use a "smart guy".
3. There was no one else around who had a clue as to what business process meant and your little knowledge resulted in you being crowned as the liege of that domain.

However, with time I have actually begun to like the business analysis part of a project as much as any other activity I perform. In the role of a business analyst, a software architect is able to obtain a coherent and extensive view of the clients needs directly. This single step in my opinion reduces a lot of issues by eliminating, what I like to call, communication "hear-tells". My increased capability in this arena has been helped along by authors, mentors and kind souls to who I owe so much. Below is a synopsis of what I have learned.

Value added analysis
In this technique, the analyst goes through each of the process flows mapped out in step one and identifies which of the activities in that flow add value to the business as a whole and which do not. As a refinement to this technique, it helps to increase the granularity by which a process activity is graded. For example, an analyst may use five grades of very high, high, medium, low and redundant to discriminate between activities that provide varying levels of utility to the business. I find color coding to be very useful at this stage. It helps visualize the areas where I need to focus on.

Constraints Analysis
In this technique we first identify where all the pain points in the business process are. Next we look to identify where work in progress piles up. Each of these points are indicators of constraints that the process is facing. These constraints are commonly referred to as bottlenecks and is a term that seems to be more easily understood. Having identified the bottlenecks, an analyst seeks to ensure that work units that are processed by this activity maximized so that the rate of units being processed (also called throughput) is maximized. There are a number of options available to the experienced analyst. These include reducing the cycle time of that activity as well as consolidation.
Besides these sophisticated techniques, however, I have found that the greatest value I can bring to the client in the role of a business analyst is to leave my thinking hat on and to use common sense with a fresh perspective. Some the questions I ask that keep me moving forward are:

• What will happen if this step goes away?
• Is this the right place to do this work?
• How does the business benefit from it?
• Can this be done elsewhere?
• Is something missing (typically information) that should be included?
• What is the history behind this?

Conclusion
While the list of questions is extensive and never ending, the goal of the activity should never be. The strength of a software architect in understanding the detail can get him enmeshed in an analysis-paralysis mode. The key symptom of this stage occurs when the goal of the quest turns into understanding all the detail rather than figuring out a solution. This can be a difficult slope to manage and sometimes is the key that differentiates a successful effort from a failed one.

Read More