Академический Документы
Профессиональный Документы
Культура Документы
Example Words or characters quoted from the screen. These include field names, screen titles,
pushbuttons labels, menu names, menu paths, and menu options.
Textual cross-references to other documents.
EXAMPLE Technical names of system objects. These include report names, program names,
transaction codes, table names, and key concepts of a programming language when they
are surrounded by body text, for example, SELECT and INCLUDE.
Example Output on the screen. This includes file and directory names and their paths, messages,
names of variables and parameters, source text, and names of installation, upgrade and
database tools.
Example Exact user entry. These are words or characters that you enter in the system exactly as they
appear in the documentation.
<Example> Variable user entry. Angle brackets indicate that you replace these words and characters
with appropriate entries to make entries in the system.
2
Document History
3
Table of contents
4
7.3 Best Practice Process .......................................................................................................................................... 34
7.4 Feature and Function Highlights ......................................................................................................................... 35
7.5 ITIL Process Integrations ......................................................................................................................................37
5
14.5 ITIL Process Integrations ...................................................................................................................................... 65
6
1 Financial Management
The objective of ITIL Financial Management for IT Services is to manage the service provider's budgeting,
accounting, and charging requirements.
Subprocess Objective
Financial Management Support Define the necessary structures for the management of financial planning
data and costs, as well as for the allocation of costs to services.
Financial Planning Determine the required financial resources over the next planning period
(IT budget) and allocate those resources for optimum benefits.
Financial Analysis and Analyze the structure of service provisioning cost and the profitability of
Reporting services. The resulting financial analysis allows Service Portfolio
Management to make informed decisions when making changes to the
service portfolio.
Service Invoicing Issue invoices for the provision of services and transmission of the invoice
to the customer.
Role Description
Financial Manager (Process The financial manager is responsible for managing an IT service provider's
Owner) budgeting, accounting, and charging requirements.
1.2 SAP Solution Manager Approach
To depict the Financial Management ITIL process in SAP Solution Manager, SAP ERP is used as a CMDB. Several
business scenarios are used. The table below describes the SAP Solution Manager approach for each of the ITIL
Financial Management subprocesses:
Financial Pricing and billing is provided by the SAP Solution Manager pricing module and the billing
Management engine.
Support The framework for planning and analyzing financial data and costs is provided by the
Controlling (CO) module of SAP ERP. This also includes the allocation of costs to services.
Capital costs and depreciations are calculated by the Asset Accounting module of SAP
ERP.
Financial The framework for planning and analyzing financial data and costs is provided by the
Planning Controlling module of SAP ERP. This also includes the allocation of costs to services.
Financial The framework for analyzing actual financial data and costs is provided by the Controlling
Analysis and module of SAP ERP. This also includes the allocation of costs to services.
Reporting Service confirmations can be used to document the usage of services and spare parts.
Actual times are automatically transferred to the time sheet CATS first and then to the
Controlling object (internal order or profitability segment).
The actual use of spare parts is transferred to the Materials Management (MM) module
first and subsequently to the controlling object (internal order or profitability segment).
Service Process
When creating a service process in SAP CRM, the characteristics relevant for CO must be
extracted. This information is used to create a Controlling object for this service process.
Service Contract
When creating a service contract in SAP CRM, the characteristics relevant for CO must be
extracted. A CO object for the service contract and its characteristics is also created.
Actual Confirmation
An actual confirmation has no reference to a service process or service contract.
Therefore, in the case of an actual confirmation, the Controlling-relevant characteristics
must be extracted directly from the confirmation and transferred to CATS/MM together
with the data necessary for posting. A Controlling object with the relevant characteristics
is then created directly for the actual confirmation.
Further information concerning the Controlling integration can be found under the
following links:
http://help.sap.com/saphelp_crm700_ehp01/helpdata/en/46/5dda00a04902f9e1000
0000a1553f6/content.htm?frameset=/en/46/55084691441ca4e10000000a155369/fr
ameset.htm
http://help.sap.com/saphelp_crm700_ehp01/helpdata/en/0a/4d88ef587649f4a9d16bf
34c487fe6/frameset.htm
http://help.sap.com/saphelp_crm60/helpdata/fr/59/b9383fdb800804e10000000a11
4084/frameset.htm
Service Invoicing Several invoicing scenarios are covered by SAP Solution Manager:
Billing After Contract Release
The order quantity for the contract is billed once the contract is released.
Transaction-Related Billing According to Order Quantity
The order quantity is billed for a transaction, for example, a credit memo request
resulting from a complaint.
Transaction-Related Billing After Completion
The order quantity is billed once a transaction (usually a service order or a service
confirmation) is completed.
Further information about billing can be found at the following links:
http://help.sap.com/saphelp_crm700_ehp01/helpdata/en/46/5501d391441ca4e10000
000a155369/frameset.htm
http://help.sap.com/saphelp_crm700_ehp01/helpdata/en/46/55084691441ca4e1000
0000a155369/content.htm?frameset=/en/46/5501d091441ca4e10000000a155369/fr
ameset.htm
Service Portfolio Management (SPM) involves proactive management of the investment throughout the service
lifecycle, including those services in the concept, design, and transition pipeline, as well as live services defined in
the various service catalogues and retired services.
The process responsible for managing the service portfolio. Service portfolio management ensures that the
service provider has the right mix of services to meet required business outcomes at an appropriate level of
investment. Service portfolio management considers services in terms of the business value that they provide.
The service portfolio is the complete set of services that are managed by a service provider. It is used to manage
the entire lifecycle of all services and includes three categories:
Service Pipeline (Status: Proposed, In Development)
Service Catalog (Status: Live, Available for Deployment)
Retired Services (Status: Retired)
Service Portfolio Management helps each customer to determine:
What services are available
What charges are associated with each service
Why they should use these services
Why they should use this specific service provider
Meanwhile, the service provider can determine:
What strengths, weaknesses, and gaps exist in their service portfolio
What their investment priorities and risks are
How their service assets (resources and capabilities) should be allocated to address these priorities and risks
SPM is an ongoing process and includes the following key activities:
Define: Collection of a validated inventory for all existing and proposed services and their business cases.
Analyze: Identification of which services are required for the organization to achieve its service goals, how
well the existing service portfolio meets these needs, which service assets are required for the service
strategy, and how to align and prioritize to meet demands.
Approve: Finalization of the desired future state of the service portfolio and authorization for retention of
appropriate existing services, and required investment in the replacement, rationalization, refactoring,
renewal, or retirement of existing services.
Charter: Communication of approved decisions relating to desired changes to the service portfolio and the
execution of actions to promote newly chartered services into service design, refresh selected existing
services in the service catalogue and initiate service transition activities.
Each service in the service portfolio is owned by a product manager (service manager). The service manager is
responsible for managing this service as a product over the entire lifecycle.
2.2 SAP Solution Manager Approach
The Service Portfolio Management in SAP Solution Manager is based on SAP CRM Service Products. Additionally,
the Project & Portfolio Management Suite of SAP can be leveraged to extend the portfolio management
capabilities.
A service product is the technical entity that represents an ITIL service object and holds all references to SLA,
other transactions related to the service or configuration items as well as service attributes such as status.
With SAP Resource and Portfolio Management (RPM), you can address the strategic aspects of Portfolio
Management, monitor project status - including information about project resources - and manage your entire
project portfolio. You can align activities, resources, and budgets with business priorities, allowing for increased
portfolio transparency, timely monitoring of portfolio performance, easier resource forecasting, avoidance of
bottlenecks, and improved decision making. These project and Portfolio Management solutions in SAP ERP, SAP
PLM, and SAP xApps composite applications seamlessly integrate with one another to give you optimal
management tools. In addition, effective project and Portfolio Management functions allow you to pool
information from different project management areas, such as HR, finance, and time-recording systems. As a
result, you can monitor and coordinate all projects in your enterprise and make optimal use of valuable resources.
The user requests a new service or the improvement of an existing service by sending a service requirement
ticket. These requirements are related to a service portfolio item and are managed as part of the Service Portfolio
Management process. The phases of the service portfolio item are reflected by the status of the service asset in
the CMS.
In general, all services have to be documented in the CMS as a service CI with one of the following statuses:
Service Pipeline: Services with the status Requirement, Design, Development, or Test
Service Catalog: Services with status Released or Operational
Retired Services: Services with the status Retired
The operational implementation of new requirements is documented and executed with requests for changes and
change documents.
2.3 Best Practice Process
ITIL Service Catalog Management aims to ensure that a service catalog is produced and maintained, containing
accurate information on all operational services and those being prepared for operation. Service Catalog
Management provides vital information for all other Service Management processes, such as service details,
current status, and interdependencies of services.
There is a clear distinction between business services in the service catalog (services visible to the customer,
defined by SLAs) and supporting services (services visible only inside the IT organization, defined by OLAs or
UCs) that are part of the technical catalog.
The service catalog is a database or structured document containing information about all live services, including
those available for deployment. The service catalog is the only part of the service portfolio published to customers
and is used to support the sale and delivery of IT services. The service catalog includes information about
deliverables, prices, contact points, ordering, and request processes.
The following roles and responsibilities occur in Service Catalog Management:
Role Description
Service Catalog Manager The service catalog manager is responsible for maintaining the service
(Process Owner) catalog, ensuring that all information in the service catalog is accurate and
up-to-date.
3.2 SAP Solution Manager Approach
The following elements are used to depict the ITIL service catalog process in the SAP Solution Manager:
SAP CRM Product Catalog
The SAP CRM service (product) master data is used to depict the service catalog in SAP Solution Manager.
While in other business scenarios (for example, a sales scenario) the SAP CRM product catalog mostly contains
physical products, in the context of an ITIL service catalog, it only contains services. In this document, the term
service catalog is used to describe the use the SAP CRM product catalog in an ITIL environment.
SAP CRM Product Hierarchy and Categories
The SAP CRM Product Hierarchy is used to depict a structured content framework for services in SAP Solution
Manager.
While in other business scenarios (for example, a sales scenario), the SAP CRM product hierarchy mostly
contains physical products, in the context of an ITIL service catalog, it is only used for services.
Therefore, in this document we refer to the service hierarchy.
Service hierarchies consist of categories and are used to group services according to different criteria. The
purpose of a hierarchy depends on the business criteria involved.
A hierarchy can contain multiple levels and can be used for control or informative purposes. All lower-level
categories inherit the set types from the higher-level category. Additional set types can be assigned to lower-level
categories.
A service can be assigned to more than one category as long as the categories belong to different hierarchies. A
service can, therefore, only be assigned to one category in each hierarchy.
Set Types
Set types are groups of service attributes that semantically belong together, e.g. Price
Set types appear as assignment blocks on a service record.
With set types you create customer-specific views of a catalog for particular business partners or target groups.
Prevent certain customers from seeing certain services in the catalog.
The creation of service records is part of Service Portfolio Management (not Service Catalog Management). When
a service record is made available for deployment (by SPM), it can be transferred to the service catalog by the
Service Catalog Manager.
Service Order Process
Create IT Service Order:
Business User selects available services from the published Service Catalog. In the Self Service UI the User
gains detailed information about the service , price and availability.
Process Service Order:
Depending on the service, the order could contain several subitems, that contribute the service delivery. The
service can be divided in several material requirements, service requests and license requirements. Each of
them will processed individually but they all are aggregated back in the service order.
It is possible to use a approval step of each subitem, before the follow up process of each process will be
triggered.
The Material requirement would need to be connected with an ERP system to process the logistic process.
The License demand can be processed with IPM ( Intellectual Property Management) capability based on SAP
CRM.
The Service Request is processed in SAP Solution Manager according the process described in chapter of
Request Fulfillment.
3.4 Feature and Function Highlights
ITIL Service Level Management (SLM) aims to negotiate service level agreements (SLAs) with the customers and
to design services in accordance with the agreed service level targets. Service Level Management is also
responsible for ensuring that all operational level agreements (OLAs) and underpinning contracts are appropriate
and for monitoring and reporting on service levels.
The table below describes the SLM subprocesses and their objectives:
Subprocess Objective
Maintenance of the SLM Design and maintain the underlying structure of the customer agreement
Framework portfolio and provide templates for the various SLM documents.
Identification of Service Identify desired outcomes (requirements from the customer viewpoint) for
Requirements new services or major service modifications. The service requirements
must be documented and submitted for initial evaluation so that
alternatives can be found at an early stage for requirements that are not
technically or economically feasible.
Agreements Sign-Off and Have all relevant contracts signed off after completion of service transition
Service Activation and check whether service acceptance criteria have been fulfilled. In
particular, this process makes sure that all relevant OLAs are signed off by
their service owners and that the SLA is signed off by the customer.
Service Level Monitoring and Monitor achieved service levels and compare them with agreed service
Reporting level targets (service level report). This information is circulated to
customers and all other relevant parties as a basis for measures to improve
service quality.
Role Description
Service Level Manager The service level manager is responsible for negotiating service level
(Process Owner) agreements and ensuring that these are met. They make sure that all IT
Service Management processes, operational level agreements and
underpinning contracts are appropriate for the agreed service level targets.
The service level manager also monitors and reports on service levels.
Service Owner The service owner is responsible for delivering a particular service in the
agreed service levels. Typically, they act as the counterpart of the service
level manager when negotiating OLAs. Often, the service owner will lead a
team of technical specialists or an internal support unit.
4.2 SAP Solution Manager Approach
To depict the Service Level Management ITIL process in SAP Solution Manager, several business scenarios are
used:
SAP CRM Service Contract Management is used to document service level agreements (SLAs), operational level
agreements (OLAs) and underpinning contracts (UCs).
SLAs, OLAs, and UCs are represented in the SAP Solution Manager as different record types. These record types
are based on the SAP service contract and contain service profiles, response profiles and service level metrics.
Service Profiles
Service profiles define the timeframes during which the IT services specified in the contract must be executed.
The service windows defined in the service profile are used as a basis for calculating the start and end dates
defined at service process level, as well as the response times.
Response Profiles
Response profiles define the periods in which the processing of the service should start and by which the
processing should be completed. The corresponding dates (first response date and completion date) are
calculated based on these periods and with reference to the service profile in the service process, which is created
with reference to the contract.
Both service profiles and response profiles can be assigned to a number of transactions, such as service request
(or incident), problem, request for change, and service order. They can be determined from different sources,
such as contracts, products, CIs, or specific customers.
Service Level Metrics
Service level metrics are criteria negotiated between a customer and service provider that define a quantitative
target that must be achieved for the service provided in a timeframe. SLMs are assigned at the contract item level.
Actual measurements can be maintained in the interface using reading either manually or automatically.
With the help of service level metrics, actual measurements can be compared to the plan values (targets).
Anomalies can then be detected and issues can be remediated.
SAP Service Contracts
Service contracts represent long-term agreements between companies and customers. In service contracts,
customers are guaranteed specific services in tolerance limits for certain parameters, for example, in a predefined
period.
The promised service (such as maintenance or hotline) is defined at contract item level. The following data is also
maintained at the service contract item level:
Service profile and response profile
See definition of service and response profile in the previous paragraph
Service Level Metrics
See definition of Service Level Metrics above
CI List
In the CI list, you assign CIs to which the service stipulated in the contract item refers.
Product List
In the product list, you enter the services and service parts that should be contained in the service stipulated
in the contract item.
Price agreements
In addition to the prices defined at header level, special price agreements can be made for each contract item.
Price agreements are contract-specific prices and discounts. You define which services are covered
completely, partially, or not at all by a contract.
In a price agreement, you can define, for example, that the customer is not charged for service parts and that
the installation of service parts should be billed at USD 25 per hour. If contractually agreed service processes
are executed, the system takes the price agreements defined in this contract into consideration during billing.
Price agreements do not have any influence on periodic contractual billing. The amounts for periodic billing
are made up of the header and item conditions in the contract.
Billing Plan
Billing plans in the contract items control periodic billing. The billing requests are generated according to
billing plans and their Customizing settings and transferred directly to the CRM Billing.
Processing Time Calculation
Processing time monitoring can be used to monitor incidents and service requests that are covered by SLAs,
OLAs, and UCs. Typically, for each SLA, OLA, and UC, the initial reaction time (IRT) and maximum processing time
(MPT) are monitored. Plan values are calculated with the help of the service profile and response profile that are
defined in the SLA, OLA, and UC records. Reporting capabilities are available to compare planned and actual
values.
4.3 Best Practice Process
The process sequence below describes the creation of a service requirement. After collection and evaluation of
the service requirements, a service contract (of type service level agreement) is created as a follow-up record to
the service requirement. Both are linked to each other, which means that at any time, the service requirement can
be accessed from the SLA and vice versa.
Finally, a service review is created as a follow-up record to the SLA.
1. Create parameters for service level agreement (SAP CRM)
The SLA parameters service profile and response profile are integrated as default settings in SAP CRM.
However, you can also freely define other company-specific parameters to support specific business
processes.
2. Create service requirement
You create a service requirement. A service requirement identifies the desired outcome (requirements from
the customer viewpoint) for new services or major service modifications. Service requirements can contain a
reference to the customer, the service provider, prices, as well as releasable products and services. These
conditions and products can be valid for service contracts that are created with reference to this service
requirement.
3. Create items in service requirement
You create the items in the service requirement. In the system, you create the services that should be agreed
upon in the service contract items as products of type service (for example, maintenance, hotline,
inspection).
4. Maintain price agreements
You maintain price agreements in the service agreement. Note that price agreements in contract items take
precedence over prices defined in the contract header.
5. Maintain product list (SAP CRM)
You maintain the product list in which you define the services and service parts that can be claimed in the
context of service order processing with reference to a service contract.
6. Create service contract
You create a service contract (of type SLA, OLA, or UC) based on the service requirement.
7. Maintain object list (CI list)
In the object list, you enter the CIs for which the service agreed upon in the service contract item can be
claimed.
8. System generates billing plan
9. System generates billing request items
10. Release service contract items and save contract
You release the items in the service contract and save the service contract.
11. System performs revenue recognition for service contracts
12. System creates and assigns appropriate controlling object
A controlling object is created for the service contract in financial accounting. Costs and revenues are posted to
the controlling object, or an existing controlling object is assigned to the service contract.
4.4 Feature and Function Highlights
The process responsible for ensuring that the capacity of IT services and the IT infrastructure is able to meet
agreed capacity- and performance-related requirements in a cost-effective and timely manner. Capacity
management considers all resources required to deliver an IT service, and is concerned with meeting both the
current and future capacity and performance needs of the business.
The main objective of ITIL Capacity Management is to provide cost-justifiable capacity in all areas of IT relevant to
current and future needs of the business. The main activities are monitoring the current capacity demand and
predicting the future capacity demand from a business, technical, and component point of view. Besides technical
monitoring, typical activities include observing trends and capacity tuning, optimizing the capacity demand by
proposing business activities, scheduling, modeling, and sizing activities.
Capacity Management in SAP Solution Manager is a comprehensive framework for monitoring and alerting
combined with an integrated data warehouse solution, the SAP Business Warehouse (BW). This allows an
integrated technical approach for Capacity Management, Availability Management, and Event Management.
The monitoring and alerting infrastructure in SAP Solution Manager provides the functionality to monitor the
capacity and availability for all Configuration Items such as applications or Infrastructure, both SAP and non-SAP.
You can define metrics thresholds for monitoring and customize event and alerting options based on these
thresholds.
This data is persisted in the integrated SAP Business Warehouse , where the customer can access predefined out
of the box reporting or extend the existing templates. This makes it easy to monitor the components and provided
services and gather information about their availability
The goal of Availability Management is to provide IT services on a cost-effective level matching or exceeding the
current and future business needs. A key activity is monitoring and controlling the availability, reliability, and
maintainability of IT services and components. Another important part of Availability Management is conducting
impact analysis, risk management, producing an availability plan, and providing information about planned service
outages.
Availability Management in SAP Solution Manager is a comprehensive framework for monitoring and alerting
combined with an integrated data warehouse solution, namely the SAP Business Warehouse. This allows an
integrated technical approach for Capacity Management, Availability Management, and Event Management.
The monitoring and alerting infrastructure in SAP Solution Manager provides the functionality to monitor the
availability not only of all relevant Configuration items such as applications or Infrastructure, both SAP and non-
SAP, but also on various layers ranging from dependent components to the defined IT service, which is usually
provided by several technical components. Thresholds can be defined for all of these metrics and you can
customize event and alerting options based on these thresholds. In addition, SAP BW, the professional data
warehouse tool, uses this availability and capacity data for standard reporting and highly flexible functionalities for
aggregating, correlating, and calculating any data and KPIs.
A Change is defined as addition, modification or removal of anything that could have an effect on IT services.
Changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and
other configuration items.
Change Management: Responsible to control the lifecycle of all changes in order to minimize downtimes of the IT
services and maximize the value resulting in a change.
Enterprises have to adapt to the new market challenges more and more frequently. These changes often result in
adaptations to the IT infrastructure and application landscape. Businesses today require their IT services to meet
these needs precisely and demand a high level of flexibility, elasticity, and thoroughness. The answer to this is a
proactive Change Management process, the aim of which is to enable changes to be implemented reliably,
economically, and on-time. The use of standardized methods and processes minimize the risks of disruption to
the IT service.
Change Management must, therefore, maintain a balance between flexibility and stability. For each change, it is
essential to weigh up the potential negative impact, for example, on availability of resources, with the anticipated
benefits of the change. The Change Advisory Board (CAB) deals with what can be a difficult decision-making
process. This board, which is comprised of highly experienced and senior key individuals, looks after the interests
of the customers and service operators. In order to take account of the time-to-market aspect, the decision-
making process must have a lean and flexible structure. To remove some of the burden from the CAB, processing
simple and routine changes must be possible without any red tape. This requires a standardized risk-assessment
process, the categorization of changes, which makes a distinction between critical and non-critical changes.
The Change Management process must enable changes to be implemented smoothly and reliably in the event of
an emergency. This requires an Emergency Change Advisory Board (ECAB), which normally comprises of two
experienced service employees.
Change Management in SAP Solution Manager is based on SAP CRM service documents. These documents are
preconfigured for Request for Change (change Request) and Change Documents (Change Records/Execution)
with experience collected by many SAP customers. The solution as part of SAP Solution Manager is called Change
Request Management and is highly integrated into the SAP environment. It provides tool support for the
processes Change Management and Release and Deployment Management. However, the tool does not just allow
you to manage SAP-related changes; all kinds of changes can be managed.
There is a standard, preconfigured process that can be automatically set up with a guided configuration
procedure. Based on this ready-to-use configuration, customers can adjust the tool to match their individual
processes, such as status values, service organization, user roles, escalation procedures, notifications, UI
adoptions, and reporting. For individual configurations, SAP offers many standard functionalities that are
available in all SAP systems (authorizations, workflows, inbound and outbound channels, and so on) as well as an
easy enhancement workbench to make individual field adjustments without the need for coding. SAP Solution
Manager comes complete with a reporting engine (SAP BW) that can be used to generate a report based on any
field in the document. You can even include this field in a dashboard (a highly-aggregated management view
report).
Change Request Management uses two main entities: The request for change, for reporting new requests for
change, and dedicated change records, for the individual execution of changes based on the evaluation performed
as part of the request for change process. This provides customers with a high level of flexibility when dealing with
changes in their enterprise.
Approval Management
You can assign an approval transaction to the request for change. This transaction must then be processed
before the request receives the status Approved. An approval transaction is an approval process that consists of a
defined sequence of approval steps. During Customizing, you can define which approval steps must be completed
for each approval transaction. You can choose which steps can run in parallel and which steps are interdependent.
For each approval step, you can also define which business partner role is responsible for executing it. If you later
select the approval transaction in the request for change, you have to assign a concrete business partner to each
step. Each business partner can be informed through a workflow item or e-mail from the SAP Business Workflow
if they need to make a decision.
To execute the approval, you can choose between three options: Approved, Rejected, and Not Relevant. In
addition, the approver can enter a comment for each approval step when executing this step. All this information
is also recorded in the change log and can be called up at any time.
You can define any number of approval transactions in Customizing. You can assign these to a request in line with
the change type. You can also use a set of rules to define your own rules. These rules can, for example, assign a
certain approval transaction on the basis of field values (for example, if the urgency and priority of the change are
very high, you need to use a different approval transaction than for a normal change).
In the standard system, SAP provides a simple approval transaction that consists of just one approval step for the
change manager. You can adjust and enhance this as required.
Tight Integration with Release and Deployment Management
Especially for SAP related changes, there is a tight integration with SAPs transport management system, which
enables clients to easily coordinate the transfer and deployment of changes throughout the landscape. This
functionality is deeply integrated into the Change Management process, including additional technical checks (for
example, the change cannot be set to Successfully Tested if the change has not reached the test environment and,
therefore, cannot be tested). The integration also helps to increase the effort for managing changes and their
release, as well as supporting the client by keeping the landscape consistent, as only tested and validated changes
are released by the system.
Actions and Conditions Framework
The solution is very flexible and allows a lot of automation for workflows and notifications. This is based on the
actions and conditions framework in the background: The Post Processing Framework (PPF) provides SAP
applications with a uniform interface for the condition-dependent generation of actions (for example, printing
delivery notes, sending email notifications, or triggering approval procedures). The actions are generated if
specific conditions are met for an application document, for example, a specific status is set (approved) or a
specific date has been reached (two weeks before end of SLA time). The actions are then processed either
directly or in a scheduled report later.
This framework allows you to define in detail what types of activity are allowed for the user (for example, change
of status) and what types of activity are triggered automatically, based on a given condition.
Examples:
Automatic escalation of the record if a defined timeframe has passed: When the initial response time is not
met or the execution of the change takes too long, the escalation level of the ticket can be raised and a
timeframe of the escalation is saved. Notifications can also be sent to relevant personnel
Management of actions that are displayed to the end user, for example, if the current status of the document
is In Development the user has other actions available, such as the status To Be Tested
Automatic setting of the request for change status if the related change record has been fulfilled: When the
change record is closed, the related request for change is set to Implemented automatically, This triggers a
notification to the change manager or requester asking them to confirm the successful change
implementation
Multilevel Categorization
The categorization plays an important role in the incident and Problem Management process. IT can define
various levels. SAP Solution Manager provides a template schema as a starting point for defining your own
categories. You first decided how many levels to use. In the standard system, the process is designed for four
levels. The person who enters the message only selects the first two levels.
The following is an example of a categorization:
Level 1: Typing the document (incident, service request, test error, alarm)
Level 2: Typing the IT area (SAP, IT hardware, mobile application)
Level 3: Typing the error (error message, crash, missing data)
Level 4: Specific error (Cannot create data in SM, Error 6734)
Good categorization offers fundamental benefits during later processing of the message.
The categorization can be used for automatic assignment to a processor or a support team, reducing the
workload of the first support level, or even bypassing them completely.
The categorization is used to propose knowledge articles with the same category to the processor. These articles
can be assigned to the incident and may already provide a solution.
The categorization is used to display problem messages with the same category (if any exist) to the incident
processor. The processor could, for example, assign the incident to a problem with the same root cause.
The category is used as the basis for displaying a template document to the processor. The processor can adopt
the template and automatically copy standard texts to the document, such as a standard response for resetting a
password.
The categorization plays an important role in evaluating incidents in order to identify trends or filter error
messages.
Service Asset and Configuration Management (SACM) supports the business by providing accurate information
and control of all assets and relationships that make up the infrastructure of an organization.
The purpose of SACM is to identify, control, and account for service assets and configuration items (CIs),
protecting and ensuring their integrity across the service lifecycle. SACM is focused on maintaining information
(that is, configurations) about configuration items (that is, assets) required to deliver an IT service, including their
relationships. Configuration Management is the management and monitoring of every aspect of a configuration
from beginning to end.
The process is responsible for ensuring that the assets required to deliver services are properly controlled, and
that accurate and reliable information about those assets is available when and where it is needed. This
information includes details of how the assets have been configured and the relationships with other CIs
The scope of SACM also extends to non-IT assets and to internal and external service providers, where shared
assets need to be controlled.
To manage large and complex IT services and infrastructures, SACM requires the use of a supporting system
known as the Configuration Management System (CMS).
Service Asset and Configuration Management in SAP Solution Manager is based on SAP CRM service documents.
These documents are preconfigured and enhanced with ITSM-specific functionalities. There is a standard,
preconfigured process that can be automatically set up with a guided configuration procedure. Based on this
ready-to-use configuration, the customers can adjust the tool to match their individual processes, such as status
values, service teams, user roles, escalation procedures, notifications, UI adoptions, and reporting. For individual
configurations, SAP offers many standard functionalities that are available in all SAP systems (authorizations,
workflows, inbound and outbound channels, and so on) as well as an easy enhancement workbench to make
individual field adjustments without the need for coding. SAP Solution Manager comes complete with a reporting
engine (SAP BW) that can be used to generate a report based on any field in the document. You can even include
this field in a dashboard (a highly aggregated management view report).
SAP Solution Manager is responsible for the process of Service asset & Configuration Management. Systems, IT
assets, Applications and any infrastructure item is stored as Configuration Item based on individual object in the
SAP CRM ibase structure.
SAP Solution Manager represents a Configuration Management System which receives CI data from several
CMDB sources. For SAP related data, input comes from a System Landscape Directory (SLD), for infrastructure
the integration to SAP IT Infrastructure Management is recommended.
CIs are used in IT services, in ITIL processes such as Incident or Change Management and provide status and
relationships to other CIs to enable impact analysis in the service processes.
8.3 Best Practice Process
Architecture of CMS
Create Configuration Items
Users can create new configuration items if required CIs are not automatically discovered.
Discovery of Configuration Items
Automated discovery is possible, for example, of a specific IP range. The discovery process can be run on demand
or scheduled for a specific time. New CIs are added to the CMS or and attributes or relationships of existing
objects are updated.
Service Asset and Configuration Management are closely integrated with other ITIL processes:
Incident Management
Provides and maintains key diagnostic information and is responsible for maintenance and provision of data to the
service desk. Each incident relates to a configuration item. Information contained in the CMS allows you to classify
(category, priority) CIs. The CMS and the service tree identify which other CIs may be affected by the incident.
Problem Management
Provides and maintains key diagnostic information and is responsible for maintenance and provision of data to the
service desk. Problem Management analyzes information in the CMS and looks for possible problems that may
arise in the future (proactive). Information contained in the CMS allows you to classify (category, priority) CIs.
Change Management
Identifies the impact of proposed changes by examining which services are affected and what the potential risks
may be. Each change of the IT infrastructure must be documented in the CMS.
CMS audit reports allow you to identify unauthorized changes.
All approved changes must be registered in the CMS.
Finical Management
Captures key financial information, such as cost, depreciation methods, owner, user (for budgeting and cost
allocation), maintenance, and repair costs.
Service Continuity Management
Identifies the assets on which the business services depend and controls key spares and software.
Service Level Management
The IT services must be documented in the CMS by referencing the CI that belongs to the service tree.
Capacity Management
Reflects capacity in CI data
Availibility Management
Reflects availability in CI status
9 Release and Deployment Management
The aim of Release and Deployment Management is to plan, schedule and control the build, test and deployment
of releases while protecting integrity of existing services, and deliver the capabilities (or skills) in accordance with
the service design specification in such a way that the service meets the requirements demanded by the
stakeholders. In order to minimize the frequency of changes to service assets and IT infrastructures and
consequently provide stability of the services for the user, multiple changes are combined into one release.
A release is a set of one or multiple changes of an IT Service where build, test and deployment will be done in a
joint fashion. A release may consists of changes for Hardware, Software, Documentation, Processes or other
components.
Issuing new releases must be closely coordinated with customers and users, as well as IT operating personnel.
The varying expectations must be skillfully managed in order to avoid potential friction following introduction. The
acceptance criteria for the releases are defined on a joint basis. Authorization from the Change Advisory Board for
the production rollout is only given after testing has been successfully concluded. In contrast to Change
Management, which is geared towards controlling and monitoring the changes, Release Management
concentrates on their implementation.
The solution as part of SAP Solution Manager is called Change Request Management and is highly integrated into
the SAP environment.
Release and Deployment Management in SAP Solution Manager is based on SAP CRM service documents. These
documents are preconfigured and enhanced with ITSM-specific functionalities and release management know-
how that was collected by SAP experts from our support organization with customers. The solution as part of SAP
Solution Manager is called Change Request Management and is highly integrated into the SAP environment. It
provides tool support for the processes Change Management and Release and Deployment Management.
However, the tool does not just allow you to manage SAP-related changes; all kinds of changes can be managed
because the configuration and framework are fully flexible.
There is a standard, preconfigured process that can be automatically set up with a guided configuration
procedure. Based on this ready-to-use configuration, customers can adjust the tool to match their individual
processes, such as status values, service organization, user roles, escalation procedures, notifications, UI
adoptions, and reporting. For individual configurations, SAP offers many standard functionalities that are
available in all SAP systems (authorizations, workflows, inbound and outbound channels, and so on) as well as an
easy enhancement workbench to make individual field adjustments without the need for coding. SAP Solution
Manager comes complete with a reporting engine (SAP BW) that can be used to generate a report based on any
field in the document. You can even include this field in a dashboard (a highly aggregated management view
report).
In SAP Solution Manager, the tool differentiates between two main types of release: releases that are related to
SAP Components and custom releases that can be assigned and related to any type of configuration item of
service that has been defined in the system.
One of the major benefits of the solution is the integration with the SAP deployment tools that help to automate
the deployment process of a release. Due to open interfaces, even non-SAP technologies can be integrated and
clients can benefit from using this tool for other technologies and software related changes or releases. SAP
Solution Manager also contains a project management suite that runs on the same installation of SAP Project and
Portfolio Management. The Project Management module enables detailed control and management of all release-
related activities.
Deployment Management
In this regard, SAP Solution Manager closes a gap that exists in many Change Management solutions for software.
When databases or lists, for example, are used to depict Change Management processes and log requests for
change and approvals, manual intervention becomes absolutely necessary when a transport request (SAP) or
generic deployment component needs to be created or imported. The ID of this component has to be copied to
the database by hand, which is a potential source of errors. A typo or mistake when copying invalidates the entire
process. With Change Request Management, transport requests are generated centrally from SAP Solution
Manager. A reference to the corresponding change record is created automatically (with the ID and description
copied to the transport requests name), enabling a clear relationship to be identified at any time. The Change
Request Management scenario lets you track all transports relating to a specific project or release, enabling you
to check where they were created and in which systems they have been imported. From SAP Solution Manager,
you can navigate to the transport logs and import queue, as well as to the SAP Solution Manager maintenance
project, the project plan, and the connected systems. Each change record provides an overview of all transports
and transport tasks created for it. From there, you can monitor the status of transports at any time and also
branch directly into the log file.
Integrated Project Management
Another great option for managing releases using Change Request Management is the integration with SAP
Project and Portfolio Management (PPM), the SAP project planning tool. A clients organization can record and
plan all the activities that need to be implemented in a release in a Project Management project plan. You can plan
resources and also establish a connection to the back end, for example, to the cross-application time sheet
(CATS) component for recording the required time for specific tasks. Changes that have undergone the approval
procedure can be scheduled here and integrated into the overall release project plan. This allows the release
manager to plan the release in detail, keeping an overview of time, budget, and all relevant resources required for
successful execution.
The Project Management component defines document templates, checklists, and entire project templates that
can be used to define release and deployment models. As part of a project template, the client can define a
structured model containing a list of tasks and milestones for a release. The document templates and checklist
templates that have been defined can be reused in project templates.
Together with the release record, this provides the full transparency for successfully managing and controlling the
execution of a release.
Test Management Integration
Test Management is a subject that is closely related to Changes and Release Management. In SAP Solution
Manager, there are numerous functions and applications for checking and administering test transactions and
test processes in the customer landscape. These functions are also integrated in Change Request Management
and the Release and Deployment Management process. For release testing, you can establish a relationship
between these release records and entities from Test Management.
The Test Management assignment block enables you to assign test plans or test packages from SAP Solution
Manager to a Change Request Management document. This enables a release manager or test coordinator, for
example, to assign a test plan in advance that contains test cases to be used for testing the planned change.
In another step, you can configure Change Request Management by implementing your own condition in such a
way that the process control is dependent on the successful execution of the assigned test packages or test plans.
This makes it possible to implement a change that, for example, enables the status to be changed from to be
tested to tested successfully only if the assigned test cases have been tested positively. This adds further stability
to your software and minimizes the risk of errors in the production system.
9.5 ITIL Process Integrations
The Release and Deployment Management is closely integrated with other ITIL processes:
Change Management
One of the most important integrations for the release and deployment process is the integration with Change
Management. Successful Change Management can only work if it interacts correctly with Release and
Deployment Management. In SAP Solution Manager, you can link any kind of release record with a related change
record, allowing full traceability for the release manager.
Service Asset and Configuration Management
A configuration item (CI) indicates which service is affected by a change. Knowledge about the relationship with
other CIs supports effective processing of the release and allows you to asses risk and impact correctly.
10 Knowledge Management
Knowledge Management is responsible for sharing perspectives, ideas, experience, and information and for
ensuring that these are available in the right place. The Knowledge Management process enables informed
decisions, and improves efficiency by reducing the need to rediscover knowledge. The Service Knowledge
Management System (SKMS) is the central repository of the data, information, and knowledge that the IT
organization needs to manage the lifecycle of its services. Its purpose is to store, analyze, and present the service
provider's data, information, and knowledge. The SKMS is not necessarily a single system; in most cases it is a
federated system based on a variety of data sources.
In SAP there are several functionalities that support Knowledge Management, such as store, subscribe, and
publish information. In the context of SAP Solution Manager ITSM solution, the core object used is the knowledge
article (KA). The KA is based on the CRM one-order concept and is, therefore, highly integrated in service records,
such as incident, problem, change, etc.. Any CI or process can include knowledge articles, which provide
particular guidance, notes, or detailed descriptions as text with different text types, with attachments or even with
further links to other knowledge databases or external URLs.
. Such information can be described as text with different text types, with attachments or even with further links
to other knowledge databases or external URLs.
A KA can have different types, such as known error, FAQ, and guide. You can categorize KAs so that while
processing incidents, changes, and so on, you can find KAs of the same category.
With standard UI functionalities, such as sharing, favorites, saved search lists, or tag clouds, it is possible to
distribute information to specific people or groups across the enterprise.
SAP Solution Manager itself has the role of a service Knowledge Management system as it collects various IT
service related information on one platform. It has references to any SAP system in the customer's IT landscape
and stores IT related information to a central place. SAP Solution Manager bundles and relates information about
business processes, applications, IT infrastructure items, IT services, business partner information, and even
reporting data, to act as an overall enterprise resource planning tool specifically to manage the IT of SAP
customers.
You can record details in a knowledge article, such as language, description, and keywords, in addition to the
categories assigned to the knowledge article. You can also record short notes, for example, about solutions or
work-arounds to problems.
You can specify administration details, such as the dates during which the knowledge article is valid, the priority of
the knowledge article, or its status.
Under the relevant assignment blocks, you can add various pieces of information, such as CIs and transactions, to
the knowledge article, as well as assign the knowledge article to other related pieces of information.
The sharing tool that is integrated in SAP Solution Manager UI framework enables you to share favorites,
predefined search and result lists, tags, or reports with others. The recipients might be individual users, groups, or
a business role (UI). With authorizations, you can control who is allowed to share or receive shared objects.
Compile knowledge bases for faster searching. When you create a knowledge article in a new language, the
system automatically creates a knowledge base index. The system automatically updates an existing index with
new or modified knowledge articles.
Attach objects, such as documents, outbound campaigns, business partners, and questionnaires to knowledge
articles, allowing access to various relevant types of information.
Use the autosuggest knowledge articles function available in the service desk. When you select a categorization
for a business transaction, the system automatically checks for knowledge articles assigned to that
categorization. If they exist, the system displays an alert from which you can navigate directly to the related
knowledge articles.
Create knowledge articles from a template to save time and also create them in various languages.
10.5 ITIL Process Integrations
Knowledge Management is closely integrated with other IT process so that it can provide information in any phase
and any situation:
Incident Management
Incidents can have references to one or more knowledge articles.
Problem Management
Problems can have references to one or more knowledge articles.
Change Management
Changes or RFCs can have references to one or more knowledge articles.
Request Fulfillment
Service requests can have references to one or more knowledge articles.
Service Catalogue Management
Services can have references to knowledge articles.
Service Asset and Configuration Management
A configuration item (CI) can have references to knowledge articles.
Availability Management
Procedures of what to do if any unexpected situations are described in the knowledge database and, therefore,
are highly available.
11 Incident Management
An incident is an unplanned interruption of an IT service or a reduction in the quality of an IT service. The aim of
Incident Management is to restore normal service as quickly as possible in order to minimize the negative impact
on operations. Incidents are often identified by means of events or alerts, or when the user contacts the service
desk. Incidents are categorized for later analysis so that responsibilities can be established. They are also
prioritized by urgency and business process impact. If an incident cannot be solved quickly, it can be escalated. A
functional escalation forwards the incident to a technical support team with the relevant expertise a hierarchical
escalation involves the relevant management levels. Once the incident has been investigated, solved and the
solution has been successfully tested, the service desk employee should check that the user is satisfied with the
solution before the incident is closed. An Incident Management tool is, therefore, crucial for recording and
managing information about the incident.
Incident Management in SAP Solution Manager is based on SAP CRM service documents. These documents are
preconfigured and enhanced with ITSM-specific functionalities. There is a standard, preconfigured process that
can be automatically set up with a guided configuration procedure. Based on this ready-to-use configuration,
customers can adjust the tool to match their individual process adoptions, such as status values, service
organization, user roles, escalation procedures, notifications, UI adoptions, and reporting. For individual
configurations, SAP offers many standard functionalities that are available in all SAP systems (authorizations,
workflows, inbound and outbound channels, and so on) as well as an easy enhancement workbench to make
individual field adjustments without the need for coding. SAP Solution Manager comes complete with a reporting
engine (SAP BW) that can be used to generate a report based on any field in the document. You can even include
this field in a dashboard (highly aggregated management view report).
You can find detailed functionality descriptions that are common in all records at:
http://help.sap.com/saphelp_crm700_ehp01/helpdata/en/0d/531976ded8475b8d29e36b4f771f58/frameset.
htm.
Escalation Process
If the IT service is subject to time restrictions in message processing, such as service agreements (SLA), it can
use the functions for SLA escalation.
The prerequisite for this is that it has defined service times and SLA agreements (that is, reaction and processing
times) on the basis of priorities. The IT objects (applications, IT hardware, and so on) have assigned SLAs or you
use a service contract to determine SLA times. In addition, the statuses that are not relevant to SLA should be
defined in the support, such as customer action or sent to SAP. This means that, over the course of processing
the message, processors continuously receive updated, calculated times by which the message should be
completed. A color bar in the document shows at all times what percentage of the reaction or processing time has
passed. If the percentage reaches 60%, the first escalation status is automatically set. If 90% is reached, the
status is raised to escalation level two. You can address this status with separate actions and, if necessary, send
e-mails to the processor or team leader to inform them of the escalation.
Multilevel Categorization
The categorization plays an important role in the Incident and Problem Management process. IT can define
various levels. SAP Solution Manager provides a template schema as a starting point for defining your own
categories. You first decided how many levels to use. In the standard system, the process is designed for four
levels. The person who enters the message only selects the first two levels.
The following is an example of a categorization:
Level 1: Typing the document (incident, service request, test error, alarm)
Level 2: Typing the IT area (SAP, IT hardware, mobile application)
Level 3: Typing the error (error message, crash, missing data)
Level 4: Specific error (Cannot create data in SM, Error 6734)
Good categorization offers fundamental benefits during later processing of the message.
The categorization can be used for automatic assignment to a processor or a support team, reducing the
workload of the first support level, or even bypassing them completely.
The categorization is used to propose knowledge articles with the same category to the processor. These articles
can be assigned to the incident and may already provide a solution.
The categorization is used to display problem messages with the same category (if any exist) to the incident
processor. The processor could, for example, assign the incident to a problem with the same root cause.
The category is used as the basis for displaying a template document to the processor. The processor can adopt
the template and automatically copy standard texts to the document, such as a standard response for resetting a
password.
The categorization plays an important role in evaluating incidents in order to identify trends or filter error
messages.
Further functions and features are described in more detail at:
http://www.service.sap.com/~sapidb/011000358700001167572011E
11.5 ITIL Process Integrations
A problem is a cause of one or more incidents. The cause is not usually known at the time a problem record is
created and the Problem Management process is responsible for further investigation. Problem Management is
responsible for managing the lifecycle of all problems. Problem Management proactively prevents incidents from
happening and minimizes the impact of incidents that cannot be prevented.
Problem Management in SAP Solution Manager is based on SAP CRM Service documents. These documents are
preconfigured and enhanced with ITSM-specific functionalities. The functionality is equal to Incident
Management. There is a standard preconfigured process that can be automatically set up with a guided
configuration procedure. Based on this ready-to-use configuration, customers can adjust the tool to match their
individual processes, such as status values, service organization, user roles, escalation procedures, notifications,
UI adoptions, and reporting. The Problem records in SAP Solution Manager are very similar to the incident or
service request record. You can find detailed functionality descriptions that are common in all records here at:
http://help.sap.com/saphelp_crm700_ehp01/helpdata/en/0d/531976ded8475b8d29e36b4f771f58/frameset.
htm.
Problem records has the ability to allocate multiple incident records to one problem. Data (status, text, and so on)
from the problem is then replicated to all referenced incidents.
In Problem Management, the causes of disruptions are investigated in order to provide solutions that prevent the
disruptive event or at least allow the event to be quickly remedied by means of documented work-arounds. All the
information relating to the disruptive event is documented in the problem record. This includes a reference to all
the incident messages that were used as the basis for creating the problem. Problem records can also be created
initially without a reference to incidents to do a trend analysis to preventing disruptive cases. Problems can also
be forwarded to SAP support or follow in RFCs.
The process is responsible for managing the lifecycle of all service requests.
The term service request is a general description for many differing types of user requests. These are
formal request from a user for something to be provided for example, a request for information or advice; to
reset a password; or to install a workstation for a new user.
Service requests are managed by the request fulfillment process, usually in conjunction with the service desk.
Many service requests are frequently made on a repeat basis so a predefined procedure - a request model - can
be used for processing and fulfilling the order. These types of request models are normally standard changes that
have already been preauthorized. The process that the request must fulfill depends to a significant extent on what
the request is. These requests are often processed in the same way as incidents in the same tool. There is,
however, an essential difference between incidents and service requests. Whereas an incident normally
represents an unplanned event, a service request can be planned. Ultimately, it is up to each organization to
decide and document which service requests are to be handled using the request fulfillment process and which
requests are to be processed using a formal RFC in Change Management.
Request fulfillment in SAP Solution Manager is based on SAP CRM service documents that are preconfigured for
Service Requests. The functionalities have been prepared so that clients can establish a request fulfillment
process quickly and easily, for example, without having to set up a service catalog first. However, if a service
catalog is available you can use this in combination with request fulfillment.
There is a standard, preconfigured process that can be automatically set up with a guided configuration
procedure. Based on this ready-to-use configuration, customers can adjust the tool to match their individual
processes, such as status values, service organization, user roles, escalation procedures, notifications, UI
adoptions, and reporting. For individual configurations, SAP offers many standard functionalities that are
available in all SAP systems (authorizations, workflows, inbound and outbound channels, and so on) as well as an
easy enhancement workbench to make individual field adjustments without the need for coding. SAP Solution
Manager comes complete with a reporting engine (SAP BW) that can be used to generate a report based on any
field in the document. You can even include this field in a dashboard (highly aggregated management view report).
In request fulfillment, the focus is on providing the right input forms for the requester to order the service in
combination with a flexible fulfillment model, allowing the service organization to easily define the necessary steps
that are executed when a particular service has been ordered.
It is possible to create individual input fields per Service as well as individual working instructions for the service
execution (called checklists)
Service Requests can be created from scratch or directly from the Service Catalog by selecting any of the
available services.
13.3 Best Practice Process
Checklists
One of the main features for request fulfillment is checklists. The checklist functionality provides the possibility for
the client to define multiple lists of activities that need to be carried out. You can use this function for step-by-step
task processing by one or more users for transactions, such as service requests. A checklist is a list of steps to be
performed by assigned step partners.
With checklists, you can select the appropriate checklist from a list of all available checklists for the transaction
type that you are creating or editing. Depending on the checklist profile settings you define in Customizing, you
can change your selection to a different checklist. However, in this case, the information contained in the previous
checklist is removed from the transaction.
Insert steps manually into the selected checklist or cancel steps that are not in status Completed and are not set
as Mandatory in Customizing, Define checklist step details, for example, required actions for each step and the
sequence in which steps are performed. Both sequential and parallel processing of checklist steps is possible.
Trigger actions, for example, launch a new transaction, from individual checklist steps. Define rules to determine
checklists as well as checklist step partners automatically. Integrate checklists with SAP Business Workflow so
that checklist step partners are notified when they have steps to carry out. If workflow is not enabled, step
partners can find their assigned steps in the agent inbox or on the search page for their business role.
More information about the functionality can also be found in this blog on the SAP Developer Network at:
http://scn.sap.com/people/bettina.giese/blog/2011/06/10/how-to-make-use-of-checklists-in-sap-crm-
service-transactions
Flexible Input Forms
As part of request fulfillment, it is possible to define a custom input form per service. This allows clients to define
their own specific user interface for the request fulfillment process, which provides their end users with a tailored
form that has been especially designed for this service.
When users request a defined service, this form is displayed and allows the users to enter specific data. Example:
Equipment Move. This service allows the end user to book an equipment move and has dedicated fields for
Current Location, Target Location, and Planned Date.
The correct form is selected automatically based on the category of the service that has been ordered. It is
possible to define an individual form for each service by using predefined custom fields or creating completely
new fields with the application enhancement tool of the UI framework.
Financial Management
The tool is capable of recording and reporting service fulfillment costs in order to charge the user with the relevant
costs for the fulfillment of the service. This data can also be transferred into the SAP ERP for further accounting
and controlling of the IT costs.
Example: The costs for an individual service fulfillment can be collected in an internal order in ERP. In the internal
order, the costs are displayed according to their cost element.
According to the ITIL standard, Event Management is a basis for operations since it recommends the ability to
detect events, define alerts, and create automatic notifications in order to support an appropriate control action.
In addition, it provides a way of comparing actual performance and behavior against design standards and SLAs.
The process is responsible for managing events throughout their lifecycle. Event management is one of the main
activities of IT operations
The general approach for event management in SAP Solution Manager is the comprehensive framework for
Application Operations combined with an integrated data warehouse solution, the SAP Business Warehouse
(BW). This allows an integrated technical approach for Capacity Management, Availability Management, and
Event Management.
The monitoring and alerting infrastructure provides the functionality to monitor all relevant technical
components, SAP and non-SAP components regarding capacity and availability. For all these metrics, exists
thresholds for event and alerting options. Furthermore SAP BW, the professional data warehouse tool, is fed with
availability and capacity and provides a standard reporting on these data.
Central Configuration
After connecting the data provider and managed object to SAP Solution Manager, the central configuration is
performed with a step-by-step configuration wizard that supports the customer with further configuration.
Different functionalities, such as auto-incidents, notification settings, or the connection to third-party
components can be adjusted according to customer needs. For the different managed objects, SAP delivers
templates that can be used right away, or easily adjusted to customer needs.
Best Practice Templates
The templates contain SAP Best Practices and Standards for Event Management and can be extended and
customized depending on the customers landscape requirements. For example, activation and deactivation of
metrics and alerts, modifications to thresholds, configuration of auto-reactions, such as Incident Management, or
notifications and custom text for adding instructions or links to help with problem resolution.
In a custom template (copy of a SAP template) it is also possible to create custom alerts based on custom
metrics. This allows a customer to create alerts based on metrics that are deemed important but are not included
in the standard. A customer can also create metrics based on preexisting data providers or from custom data
providers.
Alert Inbox
The alert inbox is the central access point to handle alerts that have been generated by the different monitoring
scenarios. It provides customers with an efficient alert handling process based on consolidation of single alerts to
alert groups, a personalized view of existing alerts, drill down capabilities from alert type to alert groups and single
metrics, and an integration of root cause analysis and collaboration features.
The generated alerts can be handled directly in the alert inbox or forwarded to other channels such as incidents, e-
mail, text messages, or third-party applications. The alert inbox also offers close integration with the various
administration and reporting capabilities of SAP Solution Manager 7.1.
Open Infrastructure
The monitoring and alerting infrastructure (MAI) alert inbox already supports forwarding of alerts as e-mails, text
messages, and incidents and there is usually no need for any further external implementation for common
consumers.
E2E MAI, however, also includes a set of open interfaces known as Alert Consumer Connector. If alerts with all
important attributes are to be forwarded to any other tool as well, this interface needs to be implemented in
appropriate way by the customer.
E2E MAI Alert Consumer Connector (E2E MAI ACC, or referred to simply as ACC) can to Push alerts to external
applications when they occur. By default, there is no mechanism supported for any external applications to Pull a
set of alerts from a store. This is consistent with the notion of explicit interfacing rather than unwarranted copy
and use of data between E2E MAI and any external application.
Auto Reaction
Once an alert has occurred in a managed object, Solution Manager displays it in the alert inbox. If you have
configured the standard autonotification and auto-incident creation features for the alert type, Solution Manager
sends notification by e-mail or text messages and creates an incident. This configuration should be carried out
during Solution Manager Configuration in Technical Monitoring.
ACC supports a mechanism through which any arbitrary code execution is possible as an automatic reaction to
selected alert types. Code executed in this way is referred to as Automatic Reaction to Alerts or just Autoreaction.
E2E MAI does not ship any autoreaction code other than the standard autonotification and auto-incident creation
features described above and, therefore, E2E MAI does not know the effect of such autoreactions.
Examples: Alerts may be forwarded to an external application, script may be triggered, or a work flow may be
started as an autoreaction. ACC only defines a set of interface methods that can be implemented by one or more
classes. Each implementation is an autoreaction that ACC invokes at an appropriate time.
Technical Analytics
In addition to the central SAP Solution Manager, where all administration, monitoring, alerting, and diagnostics
takes place, Technical Analytics provides an aggregated overview of the different managed objects' behavior over
a period of time; provides dashboards to visualize the trends in various categories such as availability,
performance, exceptions, capacity and usage. It offers real-time SLA management and reporting to
administrators, managers, and customers. Based on the trend analysis, optimization of internal processes and IT
setups is more efficient. Jump-in capability in metric viewer with zoom functionality feature offers customers
great flexibility to go from high level overview to in depth details in matter of few clicks. Technical Analytics can be
broadly classified into two groups: Technical Reporting and Management Reporting offering a wide variety of
reports addressing the needs of management and technical teams alike. Some of the reports include document-
based reports, highly interactive reports, customizable reports, and management dashboards.
14.5 ITIL Process Integrations
IT Service Continuity Management (ITSCM) is an integral part of the overall Business Continuity Management
process. The goal of ITSCM is to ensure that the minimum required IT technical and all service facilities can be
resumed within required, and agreed, business timescales after a disaster loss of normal service operation.
Due to the nature of the ITSCM process mainly documentation features, e.g. the process documentation and
documents handling, are playing a key role in organizing ITSCM with SAP Solution Manager.
The process itself may be documented and organized via the solution documentation features of SAP Solution
Manager. Process steps and responsibilities are documented and all relevant documents can be assigned to
different process steps.
All service relevant information, e.g. the unavailability costs of IT services over time in case of a disaster or the
required minimum configuration of an IT service can be documented in the Configuration Items in the iBase or
within SAP IT Infrastructure Management.
Documented service dependencies support in creating a business impact analysis and help identifying single
points of failure. Vital business functions can also be documented in the solution documentation and business
blueprint area of SAP Solution Manager.
The integrated Test Workbench allows to define and organize regular disaster recovery tests.
When establishing a tool supported ITSCM process it is extremely important to consider that the supporting tool
could also be affected by the loss of IT capabilities. That means it cannot be simply relied on the availability of all
relevant operational documents in case of a disaster. The availability of these documents like the ITSCM plan or
communication plans has to be assured by different approaches, e.g. by printed versions that are kept up-to-date
and that are stored at secure places.
High availability of SAP Solution Manager could be set up!
Initiation
During the initiation phase the ITSCM process is established within the IT organization. During this design
phase the complete process with process steps, responsibilities and relevant documents will be maintained
in the blueprint area of SAP Solution Manager. Maintain the standard steps of the process and individual
steps and maintain the process steps documentation and attributes. If ITSCM and BCM are implemented as
projects use the project administration capabilities of SAP Solution Manager additionally. Policies and other
documents can be stored in the project and blueprinting area of SAP Solution Manager.
Requirements and Strategy
In the Requirements and Strategy Phase maintain service information or use existing service information. If
not yet available add minimum configuration information for all critical IT services in the services definition
(iBase or SAP IT Infrastructure Management). Use documented dependencies for conducting a Business
Impact Analysis. The results of this analysis may also be stored in the project and blueprint area. Additional
information for the risk analysis and management can be taken from SLD, LMDB and the Monitoring and
Alerting Infrastructure (MAI) e.g. by considering information from the monitoring trees. Furthermore
recovery options may be planned and documented in SAP Solution Manager. Contracts and recovery
procedures can also be stored in the blueprinting area.
Implementation
During the implementation phase the ITSC plan and other relevant documents as the Emergency Response
Plan, a Vital Records Plan, a Crisis Management and Publiuc Relations Plan, Personnel Plans or the Security
Plan are produced and stored in the blueprinting area of SAP Solution Manager. All plans will be classified
with the current document status and document version. Furthermore walk-through tests, full tests, partial
tests or scenario tests are designed and maintained in the Test Workbench of SAP Solution Manager. These
tests may be assigned to the already documented business processes and grouped in special test plans or
the test cases and descriptions can be maintained in a special recovery testing SAP Solution Manager
project or the ITSCM project.
Ongoing Operation
During the ongoing operation some additional plans and schedules may be created and stored in SAP
Solution Manager. However it is mainly important to regularly conduct and document tests and to keep all
relevant documents up-to-date. Especially the latter must be part of the Change Management process. In
case of any major change the ITSC documents have to be updated or checked at least once a year.
Invocation
In case of a disaster invocation all information can be taken from SAP Solution Manager if it is not affected
by the disaster. In this case all information is available and features from other processes or SAP Solution
Manager features such as Incident Management, Configuration Management or the Monitoring and Alerting
Infrastructure can be used for implementing counter measures. If SAP Solution Manager is not available the
securely stored external versions of all documents have to be used.
Alert Inbox
The alert inbox is the central access point to handle alerts that have been generated by the different monitoring
scenarios. It provides customers with an efficient alert handling process based on consolidation of single alerts to
alert groups, a personalized view of existing alerts, drill down capabilities from alert type to alert groups and single
metrics, and an integration of root cause analysis and collaboration features.
The generated alerts can be handled directly in the alert inbox or forwarded to other channels such as incidents, e-
mail, text messages, or third-party applications. The alert inbox also offers close integration with the various
administration and reporting capabilities of SAP Solution Manager 7.1.
The ITSCM implementation with SAP Solution Manager mainly bases on well-known standard features of the
system.
IT Calendar Planning of periodic disaster recovery tests
The IT Calender in the Technical Administration Work Center within SAP Solution Manager provides the
possibility of a periodic scheduling of the disaster revcovery tests and allows to align these tests with
planned maintenance windows.
Project Administration and Business Blueprint
The project administration and business blueprint features of SAP Solution Manager in the transactions
SOLAR01 and SOLAR02 are used for the project administration (in case ITSCM will be implemented via a
project), for blueprinting and documenting the process ITSCM and for storing all process related documents.
If business processes are also maintained in the business blueprint attributes for identifying Vital Business
Functions may be maintained.
Service Definition
Besides the business blueprint all IT services and components are recorded via SAP Solution Manager
capabilities for Asset & Configuration Management. For details comp. chapter Asset & Configuration
Management. ITSCM simply uses the same capabilities for the documentation of minimum configurations
and uses information about dependencies between configuration items as input for risk analysis and risk
management.
Test Workbench
The SAP Solution Manager Test Workbench is also a well-known functionality of SAP Solution Manager. In a
suitable Solution Manager project, e.g. the general ITSCM project or a special ITSCM testing project the test
cases that have to be conducted for a disaster recovery test are maintained and described. These test cases
are grouped in test plans and test packages that may be assigned to testers. The test cases must contain
detailed descriptions of the testing steps that have to be conducted during a test run. Results will also be
maintained via Test Workbench features. Test cases, descriptions and test plans have to be kept up-to-date.
The IT Service Continuity Management needs an integration with further ITIL processes:
Change Management. Changes to the infrastructure and IT Services may affect the plans, procedures and
counter measures that have been established in ITSCM. Therefore close collaboration between both processes is
crucial for the process ability of ITSCM and also BCM. At least for major changes the effects on ITSCM procedures
must be assessed and if necessary changes also to the ITSCM planning must be implemented. On the other hand
changes for establishing counter measures for disaster losses of services or recovery options obviously have to
be implemented under control of Change Management.
Service Asset and Configuration Management. A configuration item (CI) indicates which service is affected in case
of the loss of the CI. The knowledge about the relation to other CIs supports the conduction of an impact analysis.
Minimum configurations can also be described in the CMDB.
Service Level Management. The Business Requirements for a service and also the minimum configuration
required in case of a disaster are described within Service Level Agreements. The Service Management offers a
tool to monitor the fulfillment of those agreements especially in case of failures.
Availability Management and Security Management. Risk analyses for ITSCM, Availability Management and
Security Management have different focus however all three may use the same information and same methods.
Despite the different focusses of these three processes there are several tasks that should not be done
redundantly.
www.sap.com/contactsap
Material Number