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.- The business analyst walked out in a huff/to new pastures at a critical time and someone had to fill in the spot.
- You wanted to learn and experience something new and your supervisor knew of a vacant position that could use a "smart guy".
- 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.
The Steps
The first step in any business process analysis is to map out the flow. This step comes intuitively to a information technology professional as it closely resembles flow charts used in the software world. In this step, each activity and decision point is mapped out as a unit of work performed by a business. This step gives you an overall idea of how the business works. It usually involves facilitated working sessions in which the business process experts contribute knowledge and experience to help in mapping out the business. Unfortunately, a lot of business process work stops at this stage itself. I have had clients who felt that mapping out the process was all they really needed from a process mapping effort and that time would be better spent in gathering requirements to automate a lot of the activities performed. This can be a short-sighted approach because there is a hidden assumption in it. The assumption is that the business process as it exists does not warrant any improvement.
A more complete approach, in my opinion, would be to go to the next step and perform a business process analysis. In this step, the analyst brings to bear powerful tools that identify weaknesses in the process and narrow down the root cause of those problems. There are many techniques that can be used to perform business process analysis. Two of the techniques that I have grown to prefer over others are:
- Value-added analysis and
- Constraints analysis
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.
posted by vivek pinto @ 7:56 AM
0 Comments:
Post a Comment
<< Home