Portfolio &Project Management on SAP Solution Manager 7.2

PM in Solution Manager 7.2 - Kishore Konathala

In short :

It plays a critical role in ALM as a poor Project Management may lead IT projects to failure, thus throwing hundreds of thousands or even millions of US dollars in the trash.

SAP Solution Manager 7.2 is the right tool for Project Managers handling implementations of SAP solutions, because it is integrated with SAP Portfolio and Project Management (PPM) 6.1. IT departments can benefit from embedded integration with other ALM processes. 

Long Story

The Project Management Institute (PMI) defines Project Management as “the application of knowledge, skills, tools, and techniques to project

activities to meet the project requirements." It plays a critical role in ALM as a poor Project Management may lead IT projects to failure, thus throwing hundreds of thousands or even millions of Euros in the trash.

The Project Manager is the person in charge to orchestrate the delivery of planned scope with high quality standards based on defined success criteria within available time, budget and resources.

There are several tools available in the market, and the most known is Microsoft Project. Although its powerful capabilities, unfortunately it cannot provide real-time progress and execution information as the statuses of tasks and activities must be previously collected and manually maintained in the tool. Another challenge companies experience is the lack of transparency of unplanned changes in the project scope due to the usage of different tools for project Planning and Execution.

SAP Solution Manager 7.2 is the right tool for Project Managers handling implementations of SAP solutions, because it is integrated with SAP Portfolio and Project Management (PPM) 6.1. IT departments can benefit from embedded integration with other ALM processes.

Finally, SAP Solution Manager 7.2 provides a Project Analysis dashboard. All project-related data and scope-related data is displayed in one view. The project analysis dashboard in SAP Solution Manager gives the customer a common view of the integrated information.

SAP Activate is a new methodology that encompasses 3 key pillars: the methodology itself, best practices and guided configuration. SAP Solution Manager 7.2 can import Work Break-down Structures (WBS) based on an XML schema supplied by SAP in few minutes to support e.g. SAP S/4HANA implementations either On-Premise, On-Cloud or Hybrid environments. All relevant phases and tasks from chosen SAP Activate methodology are described in detail, and accelerators are provided to jump-start project initiation, planning, execution and completion.

Project Management provides 3 views: detailed, or in the form of a table or a graphic. Of course, the latter is the Gantt Chart which was invented by Henry Gantt in the 1910s

PPM also offers a role-based Resource Management function. The entire lifecycle is supported, from role definition, assignment of tasks to roles, staffing of resources, and finally to assignment of assigned resources to specific tasks. The example below lists two roles, Project Manager and Developer, and provides additional information such as the remaining demand or assigned effort.

As other SAP Solution Manager capabilities, Project Management is integrated with other ALM processes such as Requirements Management, Solution Documentation and Change Request Management.

The figure below shows the solution “ACME Corporation” is assigned to the current PPM project. Hence, Solution Documentation entities can enrich project information. 

If Change Request Management (ChaRM) is enabled, a change transaction (e.g. Request for Change, aka RfC) can automatically be created out of a PPM task. This integration adds more value to the businesses because it provides more transparency and visibility of changes in the project scope, thus Project Managers can make decisions in time, and minimize the impacts.

Furthermore, it is technically possible to jump to assigned transaction type on ChaRM from a PPM project in a single mouse-click:

Last but not least, IT Project Management offers a function to Import / Export projects into Solution Manager 7.2 / to an external application. Two options are available: XML files and MS-Project.

Keep in mind this function must be used only for initial loads as upload of deltas is not supported.  

Customers can now easily create and approve business requirements in an SAP Fiori app, and exchange data across different organizations, to define and confirm project scope and scope changes easily.

To manage project scope and scope changes easily, Requirements Management and project management can be used as integrated scenario. Project managers can assign the IT Requirement and Request for Changes on each structure element of the project. The resource assigned will be transferred to the IT Requirement or Request for Change. The time the architect or developer spends on the IT Requirement, Request for Change, and/or on a Change Document, is recorded and sent to the PPM task by a background job. The Business Context viewer contains ad-hoc reporting in one click, which provides the status, and planned and confirmed times of the assigned elements.

Basis Understanding of Roles and Authorizations

Many of the Functional Consultants face issues in understanding what are the Roles and what are Authorizations in SAP. This is a document which would help people who are curious to know what is exactly the concept behind this and how does it work.

Functional Consultants have a lot of questions in mind regarding this concept and one of the main questions here is why should Functional Consultants worry about Roles and Authorization when it is a job of BASIS team.

Well, to answer this, it is not solely a job of BASIS team rather it is also like other activities, it an integrated activity which should be performed by both BASIS team and Functional team.

BASIS team have a know how about the User Management, Roles Creation, Profile Creation, Roles and Profile assignment, Authorization assignments etc. but main concern in most of the cases arises when the below questions are unanswered by BASIS team:

1. Whom to Assign the Roles or transactions
2. What to Restrict in a transaction and for whom
3. How to authorize Custom transactions

and many more such questions cannot be answered by BASIS team. Hence, it becomes the role of a Functional Consultant to guide them with the exact process flow and exact organizational chart.

Explaining with a small example here, suppose we have a maintenance team as below:

 

Supervisor – He is responsible for notifying the breakdown or Corrective Maintenance requirements

Maintenance In-charge – He is responsible for assigning the above tasks to Engineers

Head of the department – He is responsible for approving the Maintenance tasks.

 

Now, Functional Consultant is very well aware that for Supervisor would require only the transactions related to Notifications (say IW21, IW22, IW28, IW29 etc), Maintenance In-charge would require some of the notification related transactions (say IW22, IW28, IW29) and also order related transactions (IW31, IW32, IW38, IW39 etc) and the Head of the department would require notifications and order transactions (say IW28, IW29, IW38, IW39) and also along with this he require special permissions like releasing orders, approving permits, technical completions etc.

Looking from BASIS team’s perspective they are not clear with these requirements and they thus cannot take the decision for this and should be provided by Functional Consultants.

But, the main issue in most of the cases arises when Functional Consultants are not aware about the concept of Roles and Authorizations.

Hereby, this document will explain the basic concept of Roles and Authorizations:

WHAT IS ROLES AND AUTHORIZATION CONCEPT:

Roles and Authorizations allow the users to access SAP Standard as well as custom Transactions in a secure way.

SAP provides certain set of generic Standard roles for different modules and different scenarios.

We can also define user defined roles based on the Project scenario keeping below concept in mind:

There are basically two types of Roles:

Master Roles – With Transactions, Authorization Objects and with all organizational level management.

Derived Roles –With organizational level management and Transactions and Authorization Object copied from Master Role.

The reason behind this concept is to simplify the management of Roles.

WHAT ARE THE COMPONENTS OF A ROLE:

A Master Role or a Derived Role is having below components inside it:

·         Transaction Codes

·         Profile

·         Authorization Objects

·         Organization level

Transaction Codes: SAP Transaction codes (Standard or custom)

Profile: Profiles are the objects that actually store the authorization data and Roles are the Container that contains the profile authorization data.

Authorization Objects: Objects that define the relation between different fields and also helps in restricting/ allowing the values of that particular field (For ex: Authorization object I_VORG_ORD: PM: Business Operation for Orders, contains relation between fields: AUFART = Order Type and BETRVORG Business Transaction).

Authorization objects are actually defined in programs that are executed for any particular transactions. We can also create custom authorization objects for any particular transaction (generally custom transaction).

Organization level: This defines actually the organizational elements in SAP for ex: Company Code, Plant, Planning Plant, Purchase organization, Sales organization, Work Centers, etc.

Suppose we take an example of creating a role for Maintenance In-charges in a particular industry who are responsible for different maintenance plants. Consider the Scenario as under:

Company = C1, Maintenance Plants = M1, M2, M3 and M4 (Hence assuming 4 Shift In-charges).

As mentioned before, Maintenance In-charge will have rights to following transactions – IW22, IW23, IW28, IW29, IW31, IW32, IW38 and IW39 but he will not have rights to release the Maintenance order.

 

EXPLAINING WITH AN EXAMPLE:

 

Hence, considering the above situation, we will create a common Master role for all 4 Maintenance In-charges say ZMPM_MAIN_IN_CHARGE_ROLE (Here the role name starts with ZMPM to make us understand that it is a Z Master Role for Plant Maintenance ) with transaction mentioned above with all rights (with value “*”) inside the transactions but only restricting release of Maintenance order with the help of authorization object I_VORG_ORD and removing value: BFRE and field: BETRVORG but with all any organizational level (say plant) assignment.

Now based on this Master Role we have to create derived Roles for all 4 Maintenance In-charges individually say for first Maintenance In-Charge we create a derived role ZDPM_MAIN_IN_CHARGE_ROLE_MI1 referring the above Master Role ZMPM_MAIN_IN_CHARGE_ROLE. This will copy all the transactions and authorization objects from Master Role but will not copy the organizational level assignments which we have assigned in Master Role. Hence, we need to maintain the organizational level for the derived role (say Plant P1).

Here once we save (& Generate) the Master as well as Derived Role we can assign this role to the User ID for the particular Maintenance In-charge.

Process of a System Logon (ABAP)

Topic Overview :

In this Topic, you will learn about the process of a system logon, and about dialog

work process multiplexing.

Topic Objectives: 

After completing this Topic, you will be able to:

• • Describe the process of a system log on
• • Describe the technology of dialog work process multiplexing

Process of a System Logon (ABAP)

To create a connection between the front end of an end user and an instance of an SAP system, the sapgui.exe program requires various information in the form of start parameters. This parameter string is normally created by the saplogon.exe program using information about the system selected for logon. This information comes partly from the configuration files of SAP Logon, and partly from a direct request to the message server of the selected system (see steps 1 and 2 in the following figure). SAP Logon then starts the SAP GUI with these specifications.

After the transfer of the logon screen from the dispatcher to the front end (not shown in the figure), SAP GUI sends the user's logon data to the instance (step 3 in the figure). After the dispatcher has determined a free work process to process the logon, it transfers the logon data to this work process (step 4). The work process, in turn, checks whether the received combination of user ID and password is known to the system using a request to the database (steps 5-8). A positive response from the database prompts the work process to return the initial screen of the system to the front end.

During a logon session, the assignment of the user to the instance is unique. Only during a new logon can the user possibly be assigned to a different instance by the

message server.

Dialog Work Process Multiplexing

The processing of a transaction that consists of multiple screens is usually executed using multiple, different dialog work processes. This distribution is called work process multiplexing. Work process multiplexing means that a system function whose content is logically connected but consists of multiple substeps can be processed by various dialog work processes. These steps, where the content is connected, are described as transactions. A transaction that consists of multiple screens, such as screens 100 and 200 can also be processed by multiple dialog work processes.

The figure shows two screens of a transaction (100 and 200), for which the input is handled by two different dialog work processes. The multiplexing procedure is used exclusively for dialog work processes. All other work process types process entire functions; that is, complete business processes. As dialog work processes may therefore process only parts of transactions that are connected from a business point of view; the update procedure with the update work process is widely used in SAP systems.

Topic Summary

You should now be able to:

• • Describe the process of a system log on
• • Describe the technology of dialog work process multiplexing

Architecture of an SAP System

Topic Overview

In this Topic, you will learn about the structure and architecture of an SAP system, and how to use the terms system and instance correctly.

Elements of an SAP System

An SAP system consists of the components shown in the below: One database and one or more instances. The instance that, together with the database, forms a functional SAP system is also known as the “central instance”. There should be a central instance configured in every SAP system. A “central system” exists if the system contains only a single instance, and this runs together with “its” database on one host.

It is certainly possible to install two instances of a system or even of different systems on one server. Before you configure two systems (and their databases) on one server, you should examine the extent to which the chosen hardware is capable of handling the anticipated load. Other aspects to be considered are situations such as upgrades or restore scenarios (for example, one system is to be recreated from a backup whilst the other system should continue to be used without interference).
Within a company, no SAP System IDs (SIDs) should be assigned more than once. You can only exchange data between two systems with the same SID in aneffective way by going to a considerable amount of effort (renaming the systems).

What Is an Instance of an SAP System?

An instance of an SAP system is an administrative unit in which components of an SAP system that provide one or more services are combined. The services offered for an instance can be started or stopped together. Instances of an SAP system can be installed in three forms.

      1. ABAP-based instances

      2. Java-based instances

      3. ABAP/Java instances

NOTE : These three variants cannot all be installed at the same time in one SAP system. If one instance is only Java-based, the same must apply for all the other instances. Other combinations are possible (all instances ABAP-based; some instances only ABAP-based and some instances ABAP/Java-based; all instances ABAP/Java-based).

ABAP-Based Instances

First, we will take a look at pure ABAP instances.The (ABAP) dispatcher is the determining process of an ABAP instance. This

process starts other processes that belong to the instance, such as the gateway (not shown in the below), the Internet Communication Manager (ICM), and a

configured number of work processes. 

You configure an ABAP instance using an instance profile. The ABAP instance has shared (main) memory areas and its own directory structure in the file system.

An (ABAP) instance only ever has one (ABAP) dispatcher. The start of an instance always begins with the start of the associated dispatcher. An instance requires a minimum of two dialog work processes. Otherwise it is not possible to start it. You can configure several dispatchers on a host, however, these must have different instance numbers. The default for the instance number of a dispatcher is 00; that is, port 3200 receives communication for this dispatcher. Where two instances exist on a host, they are normally assigned the port numbers 3200 and 3201 etc. You can determine these instance numbers yourself to a certain extent when you install an instance. An instance number cannot be assigned more than once on a host. If several instances are installed on a shared host, these instances use their own, separate, (main) memory areas, and each instance has its own directory structure in the file system.

An (ABAP or ABAP+Java-based) SAP system can have several instances. One single instance is distinguished from all other instances, namely the (ABAP) central instance. It includes an additional process - the ABAP Message Server - which can only be configured once across the whole system. The ABAP Message Server is started before the dispatcher of the central instance. Furthermore, the central instance is the only instance that offers one or more enqueue-type work processes.

An instance is also called an application server in the software-oriented view of the client-server model. The application server provides the runtime environment

for the business applications of SAP systems.

Java-Based Instances

The (Java) dispatcher is the central process of a Java instance. This process distributes the incoming requests to the available server processes.

A Java instance only ever has one Java dispatcher. An instance requires a minimum of one server process. You can configure several dispatchers on a host,however, they must all have different instance numbers.
A (Java-based) SAP system can have several instances. One single instanceis distinguished from all other instances, namely the (Java) central instance. It includes an additional process - the Software Deployment Manager (SDM) -which can only be configured once across the whole system. There is also a Java Central Services (CS) instance. This CS instance offers the Java Message Server and the Java Enqueue Server. In a classic scenario, the Java central instance and the CS instance are located on a shared host.
You can install other Java instances on the same host as the central instance or on other separate hosts.

ABAP+Java-Based Instances

ABAP+Java-based instances offer ABAP and Java-based processes. This results in the following definition of a central instance: The central instance of an ABAP+Java-based SAP system offers all the processes of an ABAP central instance and a Java central instance.

Note : If you restart the central instance of an ABAP/+Java-based system, for example, the restart affects the following processes. Remember the definition that an instance is distinguished by the fact that all its processes can be started and stopped together.

All Java server processes
The Java dispatcher
The Software Deployment Manager (SDM), if applicable
The Internet Communication Manager (ICM)
The gateway
All ABAP work processes
The ABAP dispatcher
The ABAP Message Server

The Java Central Services instance does not belong to the ABAP+Java central instance. It is started and stopped separately.

An (ABAP+Java-based) SAP system always provides one ABAP+Java-based central instance. Other instances can be ABAP-based or also ABAP+Java-based.

Appendix: ABAP Central Services (ASCS)

As of SAP NetWeaver 7.0, for high availability (ABAP-based) SAP systems (such as SAP systems on Windows clusters) you have to set up a separate instance for central services on the ABAP side of an SAP system, namely the ABAP Central Services (ASCS). The ASCS instance enables you to separate the ABAP Message Server and the ABAP Enqueue Service (not implemented as a work process in this case) from the ABAP central instance. In the cluster you will then have the ASCS

instance and the database, as well as any number of equal ABAP instances outside the cluster. This means that there is no “central instance” (in the classic sense) in your system any more. You already know a similar concept from Java-based SAP systems in which the Java Message Server and the Java Enqueue Server are also stored in the Java Central Services instance. On the Java side you can still talk of a central instance since the Software Deployment Manager is the determining

criterion here (not to be confused with the Java Central Services instance).

Topic Summary

You should now be able to:

• • Outline the structure and the architecture of an SAP system
• • List the technical components of the SAP NetWeaver Application Server
• • Use the terms system and instance correctly