Roles in an SAP implementation project



If you are new to SAP (whether you are supporting an existing installation, entirely replacing your old enterprise software with SAP, upgrading/implementing new modules or functionality), here is a brief description of what different team members are responsible for.

Some companies decide to divide the responsibilities differently, but I am describing the most common scenario. Because this is the industry standard, job offers on portals usually follow this nomenclature.

Business user

Functional Analyst

Development

Project Manager

Security

Netweaver

Trainer

Tester

Business Users (end-users) will be using the SAP software after the go-live. They are responsible for providing the functional requirements (ie. describing what is expected from the system) to the Functional Analysts (the group they interact the most throughout the project). BUs are the ones who actually conduct the business (before the go-live: in the company’s “old” [“legacy”] system or outside of the system: on paper, in spreadsheets, etc.; after go-live: in SAP) Users are typically experts in one functional area (eg. Finance, HR, Purchasing).

Functional Analysts (Functional Consultants) gather requirements from the users and based on those design, build and test the system. This role requires at least some technical knowledge of the system (what fields are available in various transactions, how the information flows from one transaction to another, how system behavior can be changed using configuration etc). Configuration is the process of setting parameters in SAP that control the system behavior – for example, they determine which fields are visible in transaction screens, which values are allowed in certain drop-down lists etc.
Since this group is mainly responsible for actually designing the solution, it has probably the largest impact on the quality of the implementation. Designing a solution is more of an art than a science: after learning the users’ requirements, good Functional Analysts should be able to come up with a system solution that can support it. Business requirements are often ambiguous or incomplete, despite the users’ best intentions – they simply do not have experience in describing business processes. It is the FAs’ job to ask for clarifications and make sure what the users are asking really makes sense (“be careful what you wish for, you might get it”). In some cases, if a company has unique processes, the cost of building a solution may be prohibitive. Instead, the processes themselves may have to change.
FAs are also responsible for some (sometimes most – depending on the involvement of the Testing Team and Users in different phases of testing) of the testing efforts.
Most FAs have in-depth knowledge of one functional area, eg. FI (Finance) or one module, eg. SRM (Supplier Relationship Management). Others may know multiple areas, but this breadth of knowledge must necessarily come at the cost of its depth. SAP is so complicated a person can only learn so much.

Developers write custom code (mainly in a programming language called ABAP). SAP allows customers to write their own (“custom”) code that modifies the functionality of the original SAP software. The general rule is to try to minimize the amount of custom code and instead to try to achieve the desired system behavior using configuration changes, but it is not always possible. If the Functional Analysts receives a requirement which he or she can not satisfy by configuration changes, they write a Functional Specification Document (which explains the Developers what new program to write and what it should do). The disadvantage of custom code is that SAP is not responsible for supporting it. So if you decide to create (code) your own custom transaction and later there is a problem with it (eg. it does not work correctly in some scenarios), you have to find the problem and resolve it yourself. Also, in some cases new updates provided to SAP may not be compatible with your custom code.
Developers lack the business acumen and are more geeky, [oops – I meant ‘technically minded’ :-)] which is why they do not interact directly with the Users, depending instead on FAs to translate Users’ requirements into more technical terms.
Developers perform the basic testing of their own programs (“Unit testing”) before handing them over to the Functional or Testing teams.
In some European companies consultants combine the responsibilities of both the Functional Analyst and the Developer in one role.

Project Managers (Project Management Organization) track and facilitate the progress of the project and periodically report the status to the Project Sponsors. They make sure all the milestones are met on time and in case of problems – work out the recovery plan.
They do not have to have technical SAP knowledge, but it definitely helps – it allows them to quickly involve the right teams in resolving issues. Business acumen is also beneficial, so that they can easily communicate with the business stakeholders (users, sponsors).

Security Team is responsible for creating and maintaining the users’ access model. Based on the Users’ requirements, access is granted to perform certain actions in the system (eg. display/change/create certain types of document, but not others).
Change Management Team communicates with the Users about the changes that the project inevitably brings to the organization. Because implementations are very disruptive to the business, it is crucial to explain beforehand to all stakeholders the reasons and benefits of the project to get their buy-in. Change Management is mostly a soft skill and with software implementations, sometimes “the soft stuff is the hard stuff”.

Netweaver/Basis Team is very technical: they handle the software much closer to the hardware layer than any other team. They size, build and maintain the actual servers, handle all the sub-systems/environments (production/test/development); upload the actual software and updates/patches to the servers.

Trainers teach users on how to use the software. They develop the curriculum based on the design, prepare training materials and exercises and deliver them to the Users.

Testers/Quality Assurance Team is responsible for making sure that the system is properly tested before it is handed over to the users and that the testing is well documented. They maintain the test plan (the list of tests that need to be executed) and track the discovered defects until they are resolved. In some companies they build automated test cases to avoid having to perform them manually. On majority of projects, the bulk of hands-on testing is performed by Users and FAs, not the Testers.




All of the product names here are trademarks of their respective companies. This website is not affiliated with, sponsored by, or approved by SAP AG.

web analytics