INTERVIEW QUESTIONS AND ANSWERS
What is the SAP® implementation roadmap and what steps are involved
in it?
The SAP implementation roadmap is a standard process provided by SAP AG for
smooth SAP implementation and is called the ASAP Roadmap. The ASAP Roadmap
consists of five phases: (1) Project Preparation, (2) Business Blueprint, (3) Realiza-
tion, (4) Final Preparation, and (5) Going Live and Support.
FIGURE 1.1
Project Preparation—In this phase of the ASAP Roadmap, decision-makers define
clear project objectives and an efficient decision-making process. Here, project
organization and roles are defined and implementation scope is finalized.
Business Blueprint—In this phase, the scope of the R/3 implementation is defined
and the Business Blueprint is created. The Business Blueprint is a detailed docu-
mentation of the customer’s requirements.
Realization—The purpose of Phase 3 is to configure the R/3 system. The
configuration is carried out in two steps: baseline configuration and final
configuration.
INTERVIEW QUESTIONS AND ANSWERS
Final Preparation— The purpose of this phase is to complete the final
preparation of the R/3 system for going live. This includes testing, user train-
ing, system management, and cutover activities to finalize your readiness to
go live.
Going Live and Support—During this phase, the first early watch session should
be held, where SAP experts analyze the system’s technical infrastructure. The
aim is to ensure the system functions as smoothly as possible.
What does system landscape mean?
The system landscape represents the SAP system deployment at your imple-
mentation site. Ideally, in an SAP environment, a three-system landscape exists,
consisting of the development server (DEV), quality assurance server (QAS),
and production server (PRD). This kind of setup is not primarily designed to
serve as a server cluster in case of system failure; rather, the objective is to enhance
“configuration pipeline management.”
PRD
PROD
QTST
TRNG
Quality assurance
system
Production
system
FIGURE 1.2 System landscape
The system landscape is the system structure that you have for your imple-
mentation project. For example, you might have a development system, quality
assurance (QA) system, and production system. It also includes how the configu-
ration change goes through these systems and what controls there are. System
landscape mostly has to do with the systems, their servers, and so forth.
1.1 SAP-GENERAL
Specs represent specifications. In an information technology (IT) environment, you
will find two kinds of specifications: (1) functional specifications and (2) technical
specifications. These documents contain the business requirements, such as inputs,
solutions, processing logic, and so on.
Functional specification: The documentation typically describes what is
needed by the system user as well as requested properties of inputs and outputs.
The functional specification is business-oriented. A functional specification does
not define the inner workings of the proposed system, nor does it include informa-
tion for how the system function will be implemented. Instead, it focuses on what
various outside agents (e.g., people using the program, computer peripherals, or
other computers) might observe when interacting with the system.
Technical specification: While the functional specification is business-oriented,
the technical specification is system-oriented and discusses programming.
How many versions of the implementation guides (IMGs) are available
in SAP? What are they?
There are three versions of the IMG available in SAP. These are:
Reference IMG—The reference IMG contains all configuration transactions avail-
able for all functionalities/modules/submodules in the installed versions of
SAP R/3. The reference IMG represents the base set of configuration options
from which SAP functionality can be configured. All other versions of the IMG
are subsets of the reference IMG.
■
Enterprise IMG—The enterprise IMG only contains configuration transactions
that are applicable to a specific company’s installation of SAP software. The
enterprise IMG serves the purpose of filtering out configuration options that
are not required by a company if certain modules are not implemented.
■
Project IMG—A project IMG contains a subset of the enterprise IMG config-
uration transactions that need to be configured to complete a specific project.
In SAP solutions, is it possible to have a self-defined transaction code?
Yes, self-defined reports, transactions, and functions are possible within SAP
solutions. There might be numerous reasons why a company would want
INTERVIEW QUESTIONS AND ANSWERS
customized transaction codes or reports. To cater to this demand, SAP allows the
creation of user-defined transaction codes.
User-defined transaction codes allow the user to speed up access to specific
reports or programs since the user no longer needs to use transaction code SE38,
enter the program name or report name, and press Execute. Instead, the user can
simply use a predefined transaction code that will automatically open the program.
Customized T-codes can be created by using transaction code SE93. Follow these
steps to create a transaction code:
1. Name your transaction code. In this case, it is ZTEST1.
Naming a transaction code
2. Click on the Create button and then select the relevant option in the screen that
appears. In this case, select Program and selection screen.
Creating a transaction code
1.1 SAP-GENERAL
3. Click on the check mark icon at the bottom left of the screen. In the next
screen that appears, assign a program name and selection screen and save
your work. Now your transaction code ZTEST1 is ready for execution.
FIGURE 1.5 Your new transaction code
What is the best practice for transporting configuration requests? How
can you transport a configuration request?
In standard SAP implementation, there will be three clients: (1) Development,
(2) Quality, and (3) Production. These three clients may be located within one
server or on different servers for each client. Configuration will be carried out in
the Development client and transported to the Testing client. After satisfactory test-
ing of the SAP R/3 system, configuration will be transported from the Development
client to the Production client.
If different servers are used for different clients, the request is generated in
the Development client, which has to be released first through transaction code
SE10. Then the basis consultant will move the request to QUALITY through STMS,
which is really the job of the basis consultant. After thorough testing, you can again
ask the basis consultant to transport through STMS to move the request to the
Production client.
INTERVIEW QUESTIONS AND ANSWERS
Using transaction code SE10
If clients are located on the same server, transaction code SCC1 is used to trans-
port requests from one client to another client. For example, if in the Development
server itself you have the golden client (a SAP-specific word used for a good client),
i.e., DEV and one more client for Testing, you do not need to release the request in
SE10. You can do this directly through transaction code SCC1 in the Testing client
by giving the request number. Here, you may not require basis help.
