I came across many team members at various SAP implementations asking “What is my role? What am I supposed to do?”
Did you ever wonder what your role on your SAP implementations is and what you are supposed to do in your day to day job? In this blog, I captured brief functions of three main roles in any SAP implementation – Business Analyst, Functional Analyst & Technical Analyst.
Business Analyst roles:
- Serve as a liaison to the business community
- Analyze and design business processes.
- Assess current capabilities
- Identify new requirements.
- Define business requirements and use cases.
- Assist in translating requirements and use cases into test conditions and expected results.
- Participate in quality management reviews.
- Review designs, prototypes and other requirements to ensure they fulfill business requirements.
- Help in design the training and transfer knowledge to post production support team.
Functional Analyst roles:
- Translate Business requirements into Design solutions
- Develop proof of concept and conduct a Design and Build CRP (conference room pilot).
- Design configuration and customization to meet the business process design and application requirements.
- Configure the system to match the design solution.
- Identify all RICEFW objects
- Participate in testing in all RICEFW and Portal Objects.
- Complete all appropriate documentation (Example – Configuration Rationale)
Technical Analyst roles:
- Knowledge of the SAP functionality and other peripheral applications in scope.
- Translate functional specification requirements into technical requirements.
- Develop common test data.
- Configure, build, and test the application components.
- Participate in code reviews.
- Escalate any issues that may affect any other areas of the project.
- Participate in transitions of the application or technical components to the testers.
- Address defects and performance issues discovered during testing.
- Document the application steps to facilitate post production team maintain the system after deployment.
This is the model existing in most of the current and past SAP implementation.
Business Analyst interacts with Business community and communicates the requirements to Functional Analyst. Example: Requirement matrix.
Functional Analyst designs and builds the configuration elements and communicates the specification and identifies development objects and communicates this to Technical Analyst. Example: Functional Design Specification and Configuration rationales.
Technical Analyst: Designs application objects based on the Functional specifications, unit tests the designed and developed objects and fixes any defects cropped up during unit and UAT testing.
Here communication path is always from Business Analyst to Functional Analyst to Technical Analyst. Any query or concern goes though this chain and there is high probability that the communication getting distorted or lost in translation. This is a simple model that I depicted here, but in true projects you have a team of Business Analysts / leads/managers, a team of Functional Analyst/leads/managers a big team of technical Analysts/leads/managers.
This model had its own benefits, in a way that each team focuses on their tasks at hand. It works well assuming the requirements are reasonably accurate and there is no scope creep. The flipside is requirements and specification communication travels in muti stages. As the business analyst do not interact with Technical analyst or vice-versa, both of them do not gain any knowledge in other areas. Added to this if the functional analyst is not skilled enough or not a good communicator, you know what happens to the SAP implementation.
This is the future model that will be embraced by many organization and drives teams to be agile, efficient, effective and productive.
Business Analyst, Functional Analyst and Technical Analyst communicate seamlessly. This will create positive synergy leading to efficient utilization of project time and effective fulfillment of business requirement. Also all the team members gain understanding on Business, Functional and technical aspects of the project. In this model, I depicted uniform overlapping between each of these roles with the assumption that all roles are equally capable. In reality, the overlap may wary based on expertise.
Some of the benefits resulting from this model are:
- 1. Clear communication
- 2. Team members better understand requirements, design and solution.
- 3. Effective utilization of time and resources
- 4. Productive fulfillment of business requirements
- 5. Expand team member skills and knowledge area