The debate on what is it that actually takes a person to be a Business Process Expert (BPX) prompts me to write this blog with my own version. Till date there have been several implementations of SAP and most of the complex scenarios have been successfully handled by the solutions architects. Whom am I calling a Solution architect as? A person who has: • Technical knowledge and worked across functional areas • Techno-Functional experience • Moderate to very good understanding of Basis and more than one Functional areas • Handled complex requirements What makes me map this high skilled profile to that of a BPX ? Consider the following to be the requirements for a BPX, there are more than half the areas that a Solution Architect is well versed of. The other half areas are the ones in which he might have moderate to very high understanding. However there might be a few areas that he/she can improvise to be a complete BPX. For a BPX the challenges are as follows: 1. Understand the business process 2. Model the scenario 3. Able to do the configuration 4. See through the implementation 5. Manage the one odd tweaks that have to be incorporated in between 6. Understanding of the technical feasibility to the problem is also the most important item Going through the points mentioned above let us evaluate what a Solution architect is capable of and what are the qualities he/she requires Business Process: Solutions Architect mostly understands the business process for the industry/verticals they have worked in w.r.t. the functional areas such as FI, MM, SD, PP, PM, HR, PS etc. Also the advantage they have is they must have worked on the Industry Solutions provided by SAP. Modeling: It will be an added advantage here if the solutions architect has had any prior industry experience to SAP so that the required business process can be modeled by him/her. Usage of data modeling tools or ability to write Interfaces in java for the SOA is clearly a requirement in this area. Configuration: This is a major and most important step for a BPX. Understanding the requirement, modeling the scenario should lead to an understanding of the configuration requirements. A solutions architect here for sure has to have techno-functional skill in doing the same. Steps 4-6 mentioned above have more to do with the technical solution being provided to the business process and here is where a solutions architect stands to gain. Implementation: After the business blue print and configuration the major task is about carrying out the entire solution. In the emerging business dynamics and when SAP’s Netweaver is put to full use the applications are mostly distributed and hence there are lots of web services involved while a solution is built. SOA plays a major role in providing this kind of a solution and it is mandatory for anyone to build maintainable solutions using this architecture going forward. Tweaks: It is mostly impracticable to have all the minute details when a solution is built. There are some inputs that come from the users and minor changes to the business process that have to be incorporated. This could mean that the encapsulated business process needs minor tweaks. Here again the decision has to be made on what needs to be changed. Do you want to build a technical solution from within SAP? Or would you like to use a web service? Or is a configuration change required? Technical Feasibility: A solution can be modeled by a BPX but the major pinch in it is to consider if it is technically feasible. A business process guy might not be a person who can evaluate the feasibility of a solution while he/she conceptualizes. It takes a solution guy to evaluate the feasibility. Having solution architect do this job will greatly help in design of a solution without lots of rework. This is the idea and reason I have to extend a solutions architect as a BPX rather than to train a person on a varied skill set to make him a BPX. Also this is my first attempt to blog, any suggestions / recommendations to make the (future) blogs interesting are welcome.