You should know about ASAP (Accelerated SAP) methodology in which 5 phases of

implementation procedure we follow:

1. Initial Project preparation:

2. Business Blue Print

3.Realization

4.Final preparation

5. Go live and Support.

go through the SAP doc for further details.

ABAPer comes into picture in the end of the Bluprint stage.

Initially he handles most of the Enhancements, and Layout sets.

Before go live he works with Master data upload.

Reports comes in the last.

If you are working on new implementation then life cycle is same for all ..

Implementation steps:

1. AS IS process

2. To be process mapping

3. customizaiton in SAP + devepment

4. Unit testing

5. Full testing

6. End-user training

7. Go-live

8. Support for initial month-ends.

9. Ongoing support....
Basically full life cycle is ised in the context of full implementation of the project which involves
- Business Blue Print, Realization, Testing, Go live and post go live support.

End to End can be related to a particular business process. For example, we can consider Order
to Cash as end to end cycle. This will involve - creation of a Sales Order, Delivery, Billing ,
Customer Payment.

End to End is a Project starting from Initial phase to Last Phase and If you

want to know more about this go thru the material ASAP METHODOLOGY, here you

will find 5 phases this is an end to end Implementataion.

And Regarding On site, If you are sitting in Clients place and working it is

known as Onsite jon and Off Shore is sitting in your company and working for

the client is Off shore

The ABAPer responsibility is to develop the objects acording to the client requirment . ABAPers
will get the rwquirment from the FUNCTINAL PEOPLE and we will develop that by
understanding the FUNCTIONAL requirments

for your second Q?

they normally ask for example you had developed one object in MM module then they will ask
at what stag this object is helpfull in that module and how you implemented

like these q? you can face in the FUNCTIONAL terms

other than these they mainly concentrate on TECHNICAL side and your understanding of
BUSIINESS requirment

End to end Implementation means installing system which was either not there earlier or in
different kind of system.

Like earlier client was using non-erp system ,now he want to adapt ERP system , so complete
implementation( end to end ) will come into picture when we people install ERP system
succsfully with previous data which was in NON-ERP system.

second type of implementaion is in which client has NON-ERP system and he wants ERP system
in sme location , so in that case data should exist in non-erp and erp(new) both. so here cmes our
role.

how to make configuration in these two system , what are the technology to be used,i and if
succesfully all these done, it is called end-to end implementation.
This brief SAP security tutorial outlines ten key SAP security implementation steps every SAP
installation should cover, and considers how an IT security department can contribute to ensuring
the organisation has incorporated them.

1. Alignment of SAP configuration settings with organisational policies

A company’s IT security policy should specify mandatory software requirements for things such
as minimum password length, password strength, number of password fails allowed before
account lockout, etc. These requirements should be followed by all applications, and SAP is no
exception. In SAP, these settings are configurable and can be controlled using system
parameters. The parameters can be viewed using SAP transaction RSPFPAR.

Look for the following, which should all be set to follow the organisation’s predefined rules:

login/password_expiration_time (default 0, recommended 30)

Users are forced to change their SAP password after this number of days.

login/min_password_lng (default 3, recommended 8+)

Sets the minimum password length.

login/fails_to_session_end (default 3, recommended 3)

Number of times a user can enter an incorrect password before SAP ends the session.

login/fails_to_user_lock (default 12, recommended 5)

Number of times a user can enter an incorrect password before SAP locks the user master
records from further logons.

2. Access to generic user accounts

Like a lot of other application software, SAP comes with a number of generic accounts. These
are intended to be used for initial installation and setup purposes, and their passwords are well
known. It is therefore critical that these IDs are secured once the initial setup activities have been
completed.

The most critical setup ID is the SAP* ID. Its status, along with that of other generic IDs, can be
checked using the SAP report RSUSR003.

The passwords of these generic IDs should be reset, and the high-privileged profiles (SAP_ALL
and SAP_NEW) should be removed. It is important to note that the SAP* account can recreate
itself with a default and commonly known password when deleted. Accordingly, it is important
that the SAP* account is secured but not deleted and system parameter
login/no_automatic_user_sapstar is set to = 1.

3. Allocation of wide access profiles

As well as generic IDs, SAP is also delivered with a number of high-privileged generic profiles
that give wide access to the system. The allocation of these privileges should only be used in the
initial setup of the system and for subsequent emergencies. At other times, support and project
team users should have restricted access assigned to them that reflects their day-to-day access
requirements.

The most important high-privileged access profile to be aware of in the SAP system is the
SAP_ALL profile. This gives access to all transactions and authorisation objects, and, therefore,
to any function or action in the SAP system. It is critical that this profile isn’t allocated on a
routine basis. Similarly, the SAP_NEW profile gives access to all transactions and to all new
authorisation objects.

Transaction SUIM allows detailed reporting on user access. Organisations can use the report to
review the allocation of wide-access profiles to users and, using the ‘Users to Profiles’ report,
can display a list of user IDs allocated to the SAP_ALL or SAP_NEW profiles. With this
information, user access can be revised and restricted according to need.

4. Support and project team access

SAP is delivered without specific profiles or roles built for support or project team members. It is
therefore important to define these to ensure the access of these users is appropriately restricted.
In many projects this requirement is overlooked and, consequently, project team members are
assigned the SAP_ALL profile or a wide-access profile loosely based on SAP_ALL.

To ensure support and project team users have been adequately restricted, look for role
specifications outlining the access requirements of these users and a set of roles defined for each
group. Broadly speaking, at a minimum, roles defined for the following groups should be found:

 Developers
 BASIS Administrators
 Security (Role) Administration
 Security (User) Administration
 Functional / Configuration

A process should also be in place that confirms the roles are correctly defined for the
organisation’s needs.

5. Appropriate segregation of duties in role design and access administration processes

Since SAP is an integrated system, there is a risk of internal fraud if incompatible responsibilities
are allocated to the same individual. For example, if a user were to have privileges to maintain
bank account details and execute the payment run, it might be possible for him or her to bypass
controls and divert vendor payments to his or her own account.

Management and monitoring of segregation of duties (SoD) in an SAP environment is an

important part of the security process. The relevant SoD risks to the organisation’s business must
be defined, and compliance with these rules needs to be embedded into approval and access
provisioning processes.

In order to ensure segregation of duties is incorporated into the organisation’s role design and
access administration processes, a tool such as SAP GRC Risk Analysis & Remediation (RAR)
should be installed to manage these risks. Manual processes can be employed as an alternative in
smaller organisations, but the limitations of these processes (e.g. monitoring at role level as
opposed to transaction level) should be recognised and managed.

6. Emergency and high-privileged access procedures

Roles should be defined to meet the access requirements of support and project teams on a day-
to-day basis. However, it is important that these users have an escalation route available that
enables them to get access to extended rights quickly when the appropriate circumstances arise:
For example, to debug issues not replicable in a non-production system. This access should be
approved by the head of SAP application support (or a similar authority), and be allocated for a
defined period and tracked for usage.

Emergency access procedures and processes and the use of tools such as SAP GRC Super User
Privilege Management (SPM) can control and monitor the allocation and use of high-privilege
access.

7. User access and housekeeping reviews

Ongoing monitoring and review is critical in order to maintain compliance with the
organisation’s security policies and to meet the rigorous expectations that internal and external
audits have of the SAP systems. SAP system administration processes must include regular
reviews of duplicate user IDs, generic accounts, password parameters, etc., as well as the
periodic review to check that the access currently allocated is appropriate.

Whilst some of the review procedures required in an SAP environment will have activities
specific to the SAP system, the majority of such procedures should be present in any well-
controlled application environment.

8. Change management procedures

Strict adherence to change-control procedures and a transport path through development, QA/test
and production environments is critical to the integrity of the data held in the production
environment of an SAP system. SAP has an in-built transport mechanism called Change and
Transport System (CTS), and it is important that access to the key transactions used to manage
the CTS is restricted to only those administration staff members that require it to perform their
roles.

In addition to managing access to the relevant CTS functions, effective change management in
the SAP environment will also involve the operation of more generic change management
practices. These include documentation and testing of all modifications and the maintenance of
an audit trail of business approvals for all changes.

9. Access to sensitive functions

As an integrated system, sensitive administration functionality and business transactions are
accessed within the same environment in SAP. It is therefore critical that such sensitive functions
are appropriately restricted and only the individuals responsible for these activities are able to
access them.
The auditor may be able to provide a list of those functions that should be more carefully
restricted, such as the following:

 Access to maintain and create users and roles

 Access to run operating system commands
 Access to transport transactions and objects
 Access to change or create programs
 Access to open and close the system for configuration
 Access to debug programs (allowing users to bypass authorisation checks)

10. Business ownership of security processes

Business ownership of security is vital to ensure there is adequate control placed over who can
do what in an SAP system. Only the business can understand the implications of letting a
payments clerk also be in charge of paying vendor invoices or employee expense claims, so the
business must define whether this activity can be performed. It is essential, therefore, that it is
understood which members of staff are allowed access to each SAP function and that access is
constantly controlled.

Without adequate understanding and design of the permissions structures, business approvers are
not able to make informed approval decisions. It is therefore important that the SAP role design
utilised in the environment be simple enough for approvers to understand and the project include
an element of training or education for approvers, both in the initial implementation and on an
ongoing basis.

Conclusion
The advice above covers only the rudiments of security in an SAP deployment. However,
exploring these elements is intended to demonstrate that these SAP security basics are similar to
those that should be found in any well-controlled application security environment. Ultimately,
SAP is just another business application and, whilst the use of specialist SAP skills is essential to
getting things right the first time, it is also important that an organisation’s IT security
department embrace its responsibilities in the SAP deployment and not defer all responsibility to
SAP specialists.

The key is to remember that the CIO is accountable for the overall security and compliance of
the enterprise. At this level, there is little room for distinction between general IT security, such
as email, firewalls and Web servers, and SAP security, which includes the control of how people
access the system, the data they process, and the functionality they execute. Effective IT
departments adopt a similar philosophy by viewing the IT security picture in its entirety across
the whole organisation, thereby reducing the risk of breaches of any kind.
The Implementation methodology is used for implementing a project to go live.

There are 5 phases in the ASAP methodology which is the implementation methodology.

1 PROJECT PREPARATION: In which the team will be formed and you will get the kick of
meeting.

2. BUSINESS BLUE PRINT: In this you will know the business process by using the tools like
Q&A data base, FUNCTIONAL CHECK LIST,

And you will do GAP analysis if any between the Business process and the customising process
in SAP

The gap is identified using AS-IS study.

The out come of this is BPP

3. REALISATION : In this you will do all your necessary configuration like

ORGANISATIONAL strctre, DOCUMENT TYPES, OUTPUTS, AND ROUTINES, and will do
the unit testing and UAT

4. FINALISATION: here u will get the sing off on your customisation and upload the data to
the production system and data migration .

5. GO-LIVE: This will be the support after the implementation for 4-6 weeks.
ASAP Methodology: SAP Implementation Phases

What Is ASAP Methodology?

ASAP stands for Accelerated SAP. ASAP Methodology is one of the important Software
Development Life Cycle (SDLC) used for SAP Implementation projects. SAP is one of the best
ERP systems and ASAP Methodology is the way how SAP implementation happens. SAP
projects are long and intense. It requires lots of efforts and many resources from developers to
managers. It can be really tricky if SAP projects are not planned in a proper form. SAP itself
gives a proper methodology to design the project so it will give reliable results.
The ASAP methodology provides the proper framework for implementation road map. SAP
Implementation consists of several phases. These phases consist every stage of software
development life style (SDLC) for SAP implementation. ASAP Methodology divides project
according to these vital phases. Each phase is considered a milestone. Project management team
can concentrate on the current phase and start preparing for the next phase. This also provides a
better road map and work distribution. The ASAP methodology provides a framework for SAP
projects for implementation, enhancement as well customization needed for production support.

SAP Implementation Phases

6 Phases of SAP Implementation Project:

1. Project Preparation
2. Business Blueprint
3. Realization
4. Final Preparation
5. Go Live
6. Post production Support
ASAP Methodology—SAP Implementation Phases

What is SAP ? Everything you need to know about SAP software

Here is everything you need to know about SAP. You will get answers of what is SAP ? How
SAP software works ? Why SAP is one of the top ERP system ? You also get to know about
different SAP modules.
Accelerated SAP Methodology Roadmap

Which Phase of ASAP Methodology is More Important?

Phases of ASAP Methodology

The ASAP methodology includes correct pathway for SAP implementation projects. It consists 6
steps, these 6 steps are 6 major phases of SAP implementation.
SAP Implementation Phases are Presales, Preparation, Business blueprint, realization, post goes
live, post production. Here we are going to discuss all the steps in details.

1. Presale of ERP In this presale phase, ERP (SAP) try to get the project from the client. Most clients
consider more than one option for their business and then give all option a try to see which one
 provides the best result. In most cases, clients get the ERP software licence directly from the
software companies. This step may or may not include a test to check which ERP system is best
suitable for the client.
2. Preparation Once client decided its ERP system, then they prepare landscape of the project. In
this step Server information, project cost, resources, Subject Matter Experts (SME), business
teams are decided by the PMO. PMO stands for the Project Management Organization. It
consists Project Managers, Steering Committee, Core business members and sponsors. Project
team studies legacy system, gathers information regarding core systems, interfaces, what
interfaces client wants, what are necessary, what are nice to have, etc. Core team carry out as is
studying, it is the study of the current system and its processes. The project management team
also hire resources and carry out project planning and outline.
3. Business Blueprint In this phase core team carry out to be studied.Then team does GAP analysis.
It is the differences between as is and to be studied. Allocated resources write down the rules
and requirements for the new system. Integration points, interfaces and process maps are
finalized. Functional specification written by functional consultants. If needed technical
specifications written down for developers to do further configuration. Testing team also started
working on preparing testing steps and scenarios. Financial specification and technical
specifications are created in this step for further development and configurations.
4. Realization In realization step, functional consultant carried out configuration. Development is
done for the required customization. Testing carried out by the core team. Basis configuration
carried out by the security team. Basis team moves all configurations from one server to
another for testing purpose. Testing is mostly done in the quality control server. All the
configuration upload master data across all modules (sample load of few parts or entire data
end as per client wants). Unit testing and integration testing has been done by the testing team.
Unit testing, integration testing and day in the life testing happens at this stage.
5. Pre Goes Live Phase In this step, all configurations from the golden client will be moved to other
services. Uploading master data into new system mostly using LSMW, BAPI or BADI. Cut over
activities done only when we stop legacy system and start using the SAP system. End user
training and user documentation is carried out in pre go live stage. After all cuts over activities,
SAP implementation goes live in a production environment.
6. Post-Production Support In this step, the team helps client to solve if any production issue came
regarding configuration, master data change or transaction issue.Also the team will provide
training to users and super users. All the support documentation work has been completed in
this step.

In a Nutshell

ASAP Methodology is just a project implementation methodology given by SAP itself. In ASAP
methodology, project is broken down in 6 phases. This provides ease in completion and gives
easy focus for project management team.
SAP Security Implementation
1. First Steps cont.

1b. Secure SAP system

SAP comes delivered with standard passwords for special super

users. In order to secure the installation, these passwords need to

be changed. Beware, standard passwords are readily documented,

and it will be one of the first holes a hacker will try to exploit.

a. Change default passwords. Run standard report RSUSR003

to check the current status of the passwords.

b. Change passwords for database users

c. Implement password rules as described in section 1.c

d. Implement session rules as described in section 1.c

1c. Define security policy

Obtain the current security policy and identify if any existing rules

can be applied to SAP. The following rules and conventions need to

be addressed:

1. Password rules 2. Session rules

3. Logging rules 4. User termination rules

5. User id naming convention 6. Role naming convention

7. Profile naming convention 8. Output device naming convention

The implementation of these requirements is described below:

1. Password rules

a. The following instance parameter control password rules

i. login/min_password_lng = 8

Sets the minimum password length

ii. login/password_expiraton_time = 90
Set the expiration time for passwords

2. Session rules

a. The following instance parameter control session rules

i. login/disable_multi_gui_login = 1

Disable multiple dialog logons

ii. rdisp/gui_clean_delay = 0

iii. login/multi_login_users = JOEYH

List of users who can have multiple sessions

iv. login/fails_to_session_end = 3

Number of invalid logon attempts until session is terminated

v. login/fails_to_user_lock = 6

Number of invalid logon attempts until user is locked.

Lock is released at midnight

vi. login/failed_user_auto_unlock = 0

User is not unlocked if invalid attempts were made in

previous days

vii. rdisp/gui_auto_logout = 3600

Time in seconds when session is terminated after inactivity

3. Logging rules

a. The implementation of AIS allows for detailed security logging

b. Otherwise the following security items are logged in SAP:

i. Last logon/logoff

ii. Password changes

iii. User metadata changes (Example: Address, password,

default settings)
iv. Profile changes

4. User termination rules

a. How to delete users from the system

i. Establish procedure to purge users (Example: Lock user then

delete after 30 days)

ii. This policy also helps keep the installation in line with contractual

obligations with SAP. SAP periodically requests user

audits to ensure license compliance.

5. User id naming convention

a. Identify user id naming convention. The maximum is

12 characters.

b. Some example are below

i. Last + First + Initial

First Name = John, Last Name = Smith, Middle Initial = A,

Username = SMITHJA)

6. Role naming convention

a. Roles are identified by a name and a description. All roles

should follow a similar standard.

7. Profile naming convention

a. Profiles also have a name and a description. Roles generate

profiles. When roles are first saved, SAP assigns it a generated

name. In lieu of the generated name, security should utilize

a naming convention. (Example: Role name =

HQ:INV_MGR, Profile = HQ:INV_MGR)

8. Output device naming convention

a. The Basis team, in conjunction with legacy application administration

personnel, produce the names for output devices.

Output devices are usually limited to printers and FAX devices.

The importance of a naming convention comes into play when

dealing with secure devices. Examples of secure devices

include production check printers and pick printers. When

there is a logical naming convention for output devices, it

facilitates the securing process. For example, all un-secure

printers lie in the alphabetical range of A* and all secure

printers lie in the range of S*. This allows the security administrator

to identify these printers easily when building the

security roles.

1d. Define rules for securing custom objects

SAP comes delivered with thousands of standard objects such as

reports and tables, however it usually does not meet the need for

all customers. Ergo, custom objects are often created. Establishing a

standard early during the implementation will help avoid unnecessary

rework later.

Example: Define all custom tables in specific authorization groups.

If not explicitly defined, the tables become part of a default authorization

group. Changes to this require additional planning and

effort.

1e. Define standard for batch users

SAP batch jobs are scheduled and executed by a specific named

user within the system. A special named user should be created to

execute periodic batch jobs. One reason for this technique: prevent

jobs from failing after a user is purged from the system and standardize

job queries.

Example: Create a standard Human Resource (HR) user HRBATCH.

HRBATCH schedules and executes daily a job that sends timesheet

data to an external interface. The batch administrator performs a

search in SAP for jobs by username HRBATCH.

1f. Identify process for modifying security roles and users

This process becomes the process in which all security related

changes are identified and implemented. A change control process

ensures due process prior to implementing a change. The security

change control process should answer the following questions.

1. Who can request a change to an existing profile/user id

2. Who is the approving person(s) for this change

3. Who is responsible for implementing the change

4. How is the change documented and archived

1g. Define periodic audit requirements and tasks for security

In organizations with internal audit departments (IAD), audit parameters

such as frequency and extent will be defined by IAD. The

IAD will develop an audit plan and perform substantive tests in

order to validate and test internal checks and controls. During

audits, the security team’s job is to educate and assist IAD. Some

organizations also contract external auditors to perform functions

similar to IAD. During an implementation, the security team will

work with IAD or external auditors to help develop an SAP security

audit plan.

Aside from external reviews, the security team should perform periodic

checks itself. The frequency depends on resource availability

and magnitude of the implementation. The following list describes

items to check:

1. Default SAP passwords

2. Never logged in users

3. Obsolete users

4. Critical authorization holders

5. Completeness, accuracy of user records

6. Monitor locked users and frequency of locked users

1h. Define periodic security jobs

The following list describes a couple security jobs that should

run periodically:

1. Schedule PFCG_TIME_DEPENDENCY via transaction PFUD.

Create a variant for this job. This job will compare profiles

with the corresponding roles in the user master record.

2. Schedule program SAPPROFC_NEW. Create a variant for this

job. This job performs a generation of required profiles.

2. User Roles

End-user roles and project team roles are different, but they go

through a similar creation process. The following list describes the

different phases for role creation and deployment. It also highlights

the specific tasks for project team and end-user role creation

and deployment.
2a. Named user identification:

Information obtained about a named user will be used to populate

the different fields associated with that user in the SAP system.

Most fields other than user name are optional. The important

aspect of user information is consistency and completeness. Insist

on this. Gather your requirements by identifying any and all

required fields for your installation:

1. User name (system mandatory)

2. First name (optional)

3. Last name (optional)

4. Location (optional)

5. Telephone number (optional)

6. Default output device (optional)

7. Default number format (optional)

8. Default date format (optional)

9. SAP parameters (optional)

SAP Implementation & Blueprints

What is ASAP Methodology

ASAP: Accelerated Systems Application and Products in Data Processing
All implementation projects have the following phases:
Scoping - What is to be implemented i.e. which sub modules are to be implemented some clients
may not require credit management for example. Look at the project scope document carefully it
will tell you what SAP sub-modules in SAP you should be prepared for. Usually the sales people
along with project manager do it.
As is - Here you understand the existing business processes of the client . Your BPOcollect all
the ISO-documentation (if client is ISO certified), reports and forms at this stage and you analyse
how and when the reports/forms are generated, where the data is coming from. You also do a
Level -2 training for your BPO so he is made aware of all the required transactions in SAP.
Once this is over BPO can start learning with the consultants help more about SAP. This is
crucial because if you miss out any transactions the BPO may forget about some of his Business
processes which may come up later. It is a good practice to ask the BPO to make flow charts to
explain business processes.

To-Be - Parallely you map these processes to SAP. Processes that you are not sure of as to
whether they are present in SAP or not you try to do a configuration of those processes, and
along with the BPO(Business process owner he is the clients employee who knows about the
clients business processes probably a middle management guy, ther can more than one), BPO
involvement is required as he may be able to tell you his requirements better. Once you do the
business modeling you
will also be made aware of the gaps between as-is and to-be , here decisons have to be made as
to whether a ABAP development/system modification is required or not and so on. Involve the
BPO as much as possible and document everything it is good practice do not be lazy about it.

Business blueprint: Here the as-is and to-be and gap analysis is explained. This is the document
that you will be using to do your configuration in the realization phase.
Realization phase: Here you do the configuration in the development server (there are three
clients -development,quality, production). You also decide on the master data format, so that
BPO can go collect the master data. You also gove ABAP specifications for forms, reports etc,
system modifications etc. Unit testing: Your BPOs and a few key users sit down and test your
configuration in your module only. It is good to test the BDCs that you need for uploading data
at this stage so you have more realistic data and your BDCs are tested.
Integration testing:

Once all modules unit testing is over then the configuration is trasported to the Quality server,
where testing for all the modules is done by BPOs and end user, this is to check if any problems
are there in integration between various modules. Once all is okay from the QA server config is
transported to the production server.
Go live preparation
Data uploading: The collected master data is checked and the uploaded into production
server(sever and client I have used interchangeably). Now you are ready for go live i.e. users can
now use the production server.
ASAP methodology means nothing but standard process for implementation of SAP, It consists
of 5 phases.
1. Project preparation - consists of identifying team members and developing strategy as how
to go.
2. Business Blue print - consists of identifying the client current process, reqeirement and how
SAP provides solution.
Consists of detailed documentation
3. Realization -The purpose of this phase is to implement all the business and process
requirements based on the Business Blueprint.
4. Final Preparation - The purpose of this phase is to complete testing, end-user training,
5. Go Live and Support All the functinal consultatns need good rapo with Abapers. right from
uploading of legacy data, devoloping customised reports, BDC's, Forms etc, here functinal
consultatns need to give guidence as to get the requried data for reports and all.. like the table
name, fields etc
What is baseline configuration in sap?
Base line and Final config is the third phase in ASAP methadology. The purpose of this phase is
to implement all the business & process requirements based on business blue print. You
customize the system step by step in 2 work packages: Base Line Configuration & Final
Configuration.
- Base Line Configuration: this phase comprises the priority requirements of the enterprise,
ensuring that they can be implemented quickly. This phase can be completed without
programming or enhancements to SAP systems.
- Final Configuration: in this phase you confirm that all your requirements are met in the R/3
system. Final configuration is a transportation process that expands that base line solution.
Documentation which is prepared before and in a project:
1) Templates
3) Fit Gap or Gap Analysis
4) Business Process Design
5) Business Process Model
6) Business Change & Impact
7) Configuration Design, which is just 5 % of Total SAP- have different names -
8) Future Impact & Change Assessment
9) Functional Design (Module Wise)
10) Risk Assessment
11) Process Metrics and Many More-- Which has impact on Business and its work flow
Note * This documents are prepared in Vanilla SAP Standards -- Things differ from one
implementation to another, and it always depends on the type of business which is opting for
SAP.
What Are SAP End User Manual
It is the same for every other modules although here I reference it mainly for SAP HR.
1) You should understand which targeted group for the end-user training is for. Do they have any
computer background or not.
2) In what way they are going to make use of the manuals supplied to them during the course of
training.
How to prepare manuals:
In the client side, End Users are not permanent. If they get any better job outside they will resign
and go out. Even if you train them well, again the end-user team disappears after some time. That
is why implementing company( Client ) expects SAP Consultants to prepare documents which
are self explanatory (even to a layman in SAP) and study themselves and use the sap easy access
very comfortably.
Hence we should prepare a document which explains the following things comfortably:
A) All the buttons and Screens we have in sap and its importance for an end-user.
B) All the transaction codes used by end user.
C) The STEP by STEP usage methodology with screen shots and explanatory foot notes for each
Transaction code.
D) Prepare a book a table and columns which should have the following information:
- Sl.NO.
- Transaction Code
- Navigation path
- Use of the Code
- Expected Result
- Achieved Result
- Remarks/Any Comment
E) Highlight the common troubles during the usage of SAP by an end- user and give the
solutions (ready to use)
These problems you can come across while giving the in house training for the end-users. You
just place them at one place and publish it for their usage in future for any of their new join as an
end-user.
F) Every consultant is aware that the entire Organsiational Management is with end user only.
Means consultant should train the end user in entire OM.
G) We should inform the importance of info types and usage for our purposes at expert mode,
PA30, PA40 etc.,
H) Each field in the international infotypes should be explained very clearly and ensure that they
are comfortable with the fields of infotypes which have been configured for their company.
For example: info type 0001 Org Assignment insists about the three structures of the HR. We
should explain each sub field like Emp Group, Emp Sub Group, Personnel Area and Sub Area
and its importance and relevance to their company so as to understand while processing them
from the end- user point of view .
When an employee is hired into the company , now the end-user in a position to understand
which employee group and subgroup, Personnel Area And Sub Area etc., should allotted..
Like this whatever comes across in SAP Easy Access should be insisted through the training of
end users.
I) Demo, exercises and solutions should be provided in the manuals.
J) Glossary of terms and expansion of Acronyms, Abbreviations should be given. Like this each
consultant should focus on end user training and prepare the documents.
As is document:
How to start doing the project in 'AS IS' ?
Are you working as a technical person or functional person?
This work is of a functional consultant. It involves understanding the complete functionality of
the system.
It involves detailed understanding of how the HR department is functioning because based on
that only you would provide a solution to them. Like suppose you are implementing SAP HR
module for them then in the AS-IS and TO-BE phase, you need to prepare all the documents of
the process flow (you can prepare them in word). Like suppose you are implementing for PA
then you need to identify how many personnel areas you need to make, how many subareas you
will make, employee groups, subgroups, based on what you are classifying them? This all will
come in the master data document which has to be approved from the client whoever he is .
Like if the current system is on mainframe or for some specific applications like for recruitment
the system is on mainframes and the client wants to keep that system as well then interfaces need
to be identified which will be there because you will have to upload the data to sap system using
bdc.
Like this for every process there will be a document. Even for actions like:
- Hiring
- Newly Hire
- Termination
-Transfer
- Layoff etc
You will have to see what all actions your client wants, like if there is an action transfer which is
run for employee what all will be the reasons you will be configuring for that action. This will be
told by the client which can come out after a series of meetings and after discussions you will
have to come out with the document that these will be action types. These will be the action
reasons, these will be the action codes for that. This will be in the TO BE process document.
After this phase is over complete configuration can be done.
Actually AS-IS process in summary involves a :
1) Series of meeting with the client.
2) Gathering complete information about the existing system.
3) Preparation of the blue print documents describing the complete AS-IS process ,i mean the
existing system.
4) Flow charts should be included in the as-is blue print process flow document describing the
complete process.
5) After this is finished u have to give the TO-BE process structure that will be implemented in
SAP.
6) After that there will be some things which cannot be implemented in SAP so the gaps are to
be identified.
7) These gaps are to be documented in white paper for the client.
It is a lengthy process but not so difficult only the thing is that the functionality is to be
understood properly.
SAP BLUEPRINTING
Defining the Business Processes
After you have defined your organizational structure for R/3, the definition of the business
process for your Business Blueprint is the next step. You now map the enterprise requirements
onto R/3 business processes, in order to create the conceptual design for your R/3
implementation. For this, the following activities need to be carried out:
• Conducting business process workshops
• Completing the Business Blueprint, reviewing it and obtaining management signoff
• Setting up an end user training schedule
Besides determining the R/3 functionality to be implemented, the following types of
requirements should be identified in the business process workshops:
• Reporting requirements
• Interface requirements
• Conversion requirements
• Enhancement requirements
• Authorization requirements
Since all the results gathered during the workshops will subsequently create the Business
Blueprint, the importance of this step cannot be underestimated. The main tool used to define the
business processes is the Accelerated SAP Question & Answer Database in conjunction with the
R/3 Reference Model. In the process, information is gathered using the following tools:
• Business Process Questions (via R/3 Reference Model)
• Customer Input (CI) Template
• Business Process Master List
• Knowledge Corner
A functional spec should theoretically mean that the ABAPer should be able to take the design
document you have prepared, go and sit in a dark corner of the office and build the whole
report..... this rarely if ever happens, but I think that the theory.
When you write a functional spec, you are meant to be turning the clients requirements into a
design document that a techno can then build from.
Some of the things you may want to think about are:
Report logic - What information is the report trying to get, what logical links are required to link
the data together - like master data and payroll data, and org mgt data, and how should this be
linked, an imp
how should this be linked, an important bit to remember here is the time selection, do you want
all the data in the system, or only the data relevant on the day, or over a month etc.
Selection screen - What fields are required as selection options
Authorizations - Should the report check the 'runners' authorizations and tailor the output
accordingly
Output - What fields are required to be output, in what order, in what file type, for example this
could be a text file, or just out to the screen of the runner.
Error handling - What should the report do when it encounters a problem eg what scenarios
would constitute errors - what should happen etc.
Test mode - does the report require running in test mode prior to a file being produced?
What are the roles & responsibilities as a sap hr functional consultant
As a Functional Consultant, one needs to first understand the business process of the client and
then map it in SAP to accommodate those business processes.
In the Business Blueprint stage, you need to prepare AS-IS (which is a detailed list of the current
business practices of the client) and then , you need to prepare a QADB (Questions and Answer
Data Base) questionnaire and send it to the client.
Then, based on client's answers, you need to prepare TO-BE list ( procedure in SAP to match the
client's business process).You need to map AS-IS process and TO_BE process.
What are the differences between a functional and business consultant?
The difference between Functional consultant and Business consultant are as follows:
1) A functional consultant is able to configure the system unlike business consultant.
2) Functional consultant know more about business process unlike Business consultant.
3) A business consultant will bring business process knowledge and provide it to functional
consultant who in turn used this knowledge to configure the system.
4) Functional consultant has more configuration knolwledge then Business consultant
The responsibilities of a support consultant are:
- Primarily responsible for Handling tickets and application support to the endusers
- When an issue comes diagnose, analyse and solve the issue
- Responsible for any enhancements
- Writing functional specs and interacting with Abapers to develop any user exits
- Training the end users and preparing end user training material
For those who wished to know the role of a functional consultant. Below is one view:
A functional consultant evaluates the demands in talking with the customer\'s representatives,
transforms the essence into an abstract and algorithmic business model. Hence, he identifies the
use cases and transforms them into logical and technical views.
Then the main task starts: customizing the respective business area and making sure the system
reacts in the manner according to the constraints of the requested use case.
The consultant documents the settings and prepares proper guidelines that allow other
consultants to do further changes or repairs with due efforts.
The consultant takes care that proper training is given to the users and that the system is usable,
performing appropriately and the business flow is complete and correct.
During go live he assists the technical staff by testing the behaviour of the system.
After go live he guarantees that the procedures remain usable and consistent in real live situation
and proposes.
The consultant takes care that proper training is given to the users and that the system is usable,
performing appropriately and the business flow is complete and correct.
During go live he assists the technical staff by testing the behaviour of the system.
After go live he guarantees that the procedures remain usable and consistent in real live situation
and proposes enhancements.
The main duty of a consultant is to transfer external know-how to the client. It is not manpower
that counts but intelligence, understanding of processes, a feeling for defects and general a
common sense.
Role of a Functional Consultant in an End To End Implementation
1. Functional consultant is expected to generate knowledge about the current business process,
design current business flows, study current business processes and its complication, in all we
can say getting through with current business setup. Flow diagrams and DFD are prepared, most
of the time in Vision format, all this forms the part of AS IS document.
2. Everything configured has to be documented as per their categories in the form of predefined
templates, these have to be then approved by the team leads or who ever the consultant is
reporting to.
3. Mapping and GAP analysis is done for each module, I have seen people defining integration
after mapping, gap analysis and configuration is done, but as per my experience in
implementation, it is a simultaneous process.
4. Before starting configuring future business processes in SAP, the DFD/ERD are prepared, this
documentation is called TO BE, which can be also siad as the result of mapping and gap
analysis.
5. Sometimes Functional consultants are also expected to prepare test scripts for testing the
configured scenarios.
6. End user manual and user training is also expected from F.Consultants.
The project normally starts off with a Kick off meeting in which the team size, team members,
reporting system, responsibilities, duties, methodlogy, dates and schedules, working hours which
have been predicided are working hours which have been predicided are formally defined.

SAP Landscape is like a server system or like a layout of the servers or some may even call it the
architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and
PROD.
- DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.
- QAS may again have multiple clients for ex: 300- Integration Test, 700 to 710 Training.
- PROD may have something like a 200 Production.
These names and numbers are the implementer's discreet on how they want it or they have been
using in their previous implementations or how is the client's business scenario.
Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you
think you are satisfied with your configuration and you think you can use it moving forward, you
RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use
it for rough usage). As you re-do everything that you had thought was important and usable, you
get a transport request pop up upon saving everytime. You save it under a transport request and
give your description to it. Thus the configuration is transported to the Unit Test client (180 in
this example).
You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden)
client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you
have all the configuration in the Testing client, just as it is in the Golden client. The
configuration remains in sync between these two clients.
But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction
only client where you perform the unit test. Upon a satisfactory unit test, you move the good
configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is
corrected in Golden (may again as well be practised in the sandbox prior to Golden) and
accordingly transported back to 180 (Unit Test) until the unit test affected by that particular
config is satisfactory.
The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the
'ultimate' reference client for all the good, complete and final configuration that is being used in
the implementation.
In summary:
Landscape : is the arrangement for the servers
IDES : is purely for education purpose and is NOT INCLUDED in the landscape.
DEVELOPMENT ---> QUALITY ----> PRODUCTION
DEVELOPMENT : is where the the consultants do the customization as per the company's
requirement.
QUALITY : is where the core team members and other members test the customization.
PRODUCTION : is where the live data of the company is recorded.
A request will flow from Dev->Qual->Prod and not backwards.
These three are landscape of any Company. They organised their office in these three way.
Developer develop their program in Development server and then transport it to test server. In
testing server tester check/test the program and then transport it to Production Server. Later it
will deploy to client from production server.
Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.