solman confguration.pdf

8/22/2019 solman confguration.pdf

1/53

SAPStandard: Solution Documentationfor Custom Development

2008 SAP AGS SAP Standard Solution Documentation for Custom Page 1 of 53

Version: 1.0

August 2008

Solution Documentation forCustom Development

Active Global Support

SAP AG

Development Version: 1.0


2/53


1 MANAGEMENT SUMMARY .................................................................... 42 SAP STANDARDS FOR E2E SOLUTION OPERATIONS....................... 53 SOLUTION DOCUMENTATION FOR CUSTOM DEVELOPMENT AT A

GLANCE .................................................................................................. 83.1 Documentation Content ........................................................................................................ 83.2 Location and Format of Documentation Content .......................................................... 83.3 Documentation Language .................................................................................................... 94 REQUIREMENTS FOR MINIMUM DOCUMENTATION CONTENT ...... 104.1 Create a Project in SAP Solution Manager.................................................................... 104.2 System and Appli cation Landscape ................................................................................ 124.3 Physical System Landscape ............................................................................................. 144.4 Solution Definition ............................................................................................................... 154.5 Appl ication Components and Custom Namespaces .................................................. 164.6 Business Scenario and Business Process Documentation ...................................... 174.7 Interface Documentation .................................................................................................... 224.8 Documentation of Background Jobs .............................................................................. 224.9 Transactions and User Entry Points ............................................................................... 244.10 Performance and Volume KPIs ......................................................................................... 254.11 Development object list for Custom Development or Customizing Objects ........ 254.12

Functional Documentation / Business Background

................................................... 274.13 Integration and Volume Test Plan Documentation ...................................................... 284.14 Appl ication Operations Guide........................................................................................... 28

2008 SAP AGS SAP Standard Solution Documentation for Custom Page 2 of 53Development Version: 1.0


3/53


5 APPENDIX.............................................................................................. 305.1 Template: Application Components and Namespaces .............................................. 305.2 Template: Interface Documentation ................................................................................ 325.3 Template: Job L ist ................................................................................................................ 345.4 Template: Performance and Volume KPIs ..................................................................... 355.5 Template: Functional Documentation ............................................................................. 365.6 Template: Test Plan Documentation ............................................................................... 385.7 Template: Application Operations Guide ....................................................................... 50



4/53


1 Management Summary

With the increasing number of systems and technologies, the complexity of IT solutions isrising. The key to successful landscape planning and operation is an accurate and completedescription of the solution landscape itself with all business processes. All reporting is basedon this fundamental information. As part of SAPs standards for End-to-End Solution Opera-tions, the standard for Solution Documentation describes in general how customers achievethe required transparency of their SAP solution.

For SAP applications, a lot of documentation is already provided by SAP. For functionalitydeveloped by customers or third-party software providers, the availability of required docu-mentation is not ensured. Therefore, additional requirements regarding solution documenta-tion exist for such custom developments. This document describes the content of the re-quired documentation as well as tools and formats to be used to deliver it. At least the speci-fication of the development project, a list of all related code objects, and of the required con-

figuration settings have to be available. This helps both customer support organizations andSAP Active Global Support to deliver support for custom developments effectively.

This paper starts with a brief overview of the end-to-end solution operations standards. Thenit describes the general motivation and basic requirements regarding solution documentationfor custom developments in chapter 3. Content of chapter 4 of this document is an explana-tion of what has to be documented and where to store the information. Finally, the appendix(chapter 5) displays templates which can be utilized for solution documentation of customdevelopments.



5/53


2 SAP Standards for E2E Solution Operations

Mission-critical operations is a challenge. While the flexibility of SAP-centric solutions rises,customers have to manage complexity, risks, costs, as well as skills and resources efficiently.Customers have to run and incrementally improve the IT solution to ensure stable operationof the solution landscape. This includes the management of availability, performance, proc-ess and data transparency, data consistency, IT process compliance, and other tasks.

Typically, multiple teams in the customer organization are involved in the fulfillment of theserequirements. They belong to the key organizational areas Business Unit and IT. While thenames of the organizations may differ from company to company, their function is roughly thesame. They run their activities in accordance with the corporate strategy, corporate policies(for example, corporate governance, compliance and security), and the goals of their organi-zations.

Figure 2.1: Organizational model fo r end-to-end solution operations

The different teams specialize in the execution of certain tasks: On the business side, endusers use the implemented functionality to run their daily business. Key users provide first-

level support for their colleagues. Business process champions define how business proc-esses are to be executed. A program management office communicates these require-ments to the IT organization, decides on the financing of development and operations, andensures that the requirements are implemented.



6/53


On the technical side, the application management team is in direct contact with the busi-ness units. It is responsible for implementing the business requirements and providing sup-port for end users. Business process operations covers the monitoring and support of thebusiness applications, their integration, and the automation of jobs. Custom developmenttakes care of adjusting the solution to customer-specific requirements and developments.SAP technical operations is responsible for the general administration of systems and de-tailed system diagnostics. And the IT infrastructure organization provides the underlying ITinfrastructure (network, databases ). Further specialization is possible within these organi-zations as well. For example, there may be individual experts for different applications withinSAP technical operations.

Efficient collaboration between these teams is required to optimize the operation of SAP-centric solutions. This becomes even more important if customers engage service providersto execute some of the tasks or even complete processes. Customers have to closely inte-grate the providers of outtasking and outsourcing services into the operation of their solu-tions.

Key prerequisite for efficient collaboration of the involved groups is the clear definition ofprocesses, responsibilities, service level agreements (SLAs), and key performance indicators(KPIs) to measure the fulfillment of the service levels. Based on the experiences gained bySAP Active Global Support while serving more than 40,000 customers, SAP has definedprocess standards and best practices, which help customers to set up and run End-to-End(E2E) Solution Operations for their SAP-centric solutions. This covers not only applicationsfrom SAP but also applications from independent software vendors (ISVs), original equipmentmanufacturers (OEMs), and custom code applications integrated into the customer solution.

There are 16 standards for solution operations defined by SAP:

Incident Management describes the process of incident resolution

Exception Handling explains how to define a model and procedures to manage ex-ceptions and error situations during daily business operations

Data Integri ty avoids data inconsistencies in end-to-end solution landscapes

Change Request Management enables efficient and punctual implementation ofchanges with minimal risks

Upgrade guides customers and technology partners through upgrade projects

eSOA Readiness covers both technical and organizational readiness for enterpriseservice-oriented architectures (eSOA)

Root Cause Analysis defines how to perform root cause analysis end-to-end acrossdifferent support levels and different technologies

Change Control Management covers the deployment and the analysis of changes

Solution Documentation and Solution Documentation for Custom Developmentdefine the required documentation and reporting regarding the customer solution



7/53


Remote Supportability contains five basic requirements that have to be met to op-timize the supportability of customer solutions

Business Process and Interface Monitoring describes the monitoring and supervi-sion of the mission critical business processes

Data Volume Management defines how to manage data growth

Job Scheduling Management explains how to manage the planning, scheduling,and monitoring of background jobs

Transactional Consistency safeguards data synchronization across applications indistributed system landscapes

System Administration describes how to administer SAP technology in order to runa customer solution efficiently

System Monitoring covers monitoring and reporting of the technical status of IT so-

lutions

Out of this list, this white paper describes the standard Solution Documentation for Cus-tom Development.



8/53


3 Solution Documentation for Custom Development

at a GlanceThe functionality delivered by standard applications does not always match completely withthe requirements of a customer. Therefore, some projects may include the development ofadditional functionality or the change of existing functionality. These custom developmentsmay be done by customers themselves, by third-party companies, or by SAP Custom Devel-opment.

3.1 Documentation Content

Supporting such customer developments is often more difficult than the support of standardapplications. A standard application is typically used by more customers than a specific cus-tom development. In most cases, there is much more support experience regarding a stan-dard application than there is regarding a custom development. And the risk gets even higherif the people involved in the development project have left the customer or the involved third-party company has vanished. Therefore, proper documentation of custom developments isespecially important:

Which parts of the project are impacted by the custom development?

Why has the custom development been done (business background)?

Which systems are involved?

Are there any dependencies between the custom development and other sys-tems/functions?

Which business processes and process steps are changed?

What are the transactions or entry points of the custom development?

Which interfaces are used to integrate the custom development with standard appli-cations?

Which development objects have to be transferred from development to quality as-surance and production system?

How to operate the custom development?

How to set up and execute integration and volume test for the custom development?

3.2 Location and Format of Documentation Content

The minimum documentation required for custom development projects shall be stored withinthe project documentation tools provided in SAP Solution Manager 4.0 located in the cus-tomer solution environment. In case of multiple SAP Solution Managers in the customer land-scape it is expected that the complete set of minimum documentation is located within theSAP Solution Manager that is also used for managing operations and maintenance tasks for



9/53


the involved system landscape. It is possible to start a project within one SAP Solution Man-ager during the development phase and later on transfer it to another SAP Solution Manager.

In order to ensure the optimal delivery of SAP support services, it is important for SAP to findthe minimum documentation in a standardized location and format. On the other hand, thislays the ground for leveraging many operation support functions offered via SAP SolutionManager (e.g. identification of affected custom business process by requested software orcustomizing change requests). Certain parts of the documentation are required to be storedin structured format for those parts the project documentation in SAP Solution Manageroffers dedicated screens and structuring elements that shall be used. For unstructured typeof information (textual descriptions), there are special template documents provided that shallbe used to provide this information. Which information is expected in which format is ex-plained in chapter 4.

3.3 Documentation Language

It is required that all documentation requested within this document is provided in English. Incase where SAP services shall cover this project it is important that SAP support engineersare able to read it. Without additional translation effort, this can only be guaranteed in a 24x7mode if the documentation is available in English.



10/53


4 Requirements for Minimum Documentation Con-

tentDocumentation can be extensive. To keep your focus on the information that is required mostimportantly, this chapter describes the key documentation for custom developments. Youlearn how to maintain this documentation within SAP Solution Manager.

4.1 Create a Project in SAP Solut ion Manager

A container is required to collect all documentation regarding your custom development pro-ject. In SAP Solution Manager, these containers are called projects. Use transactionSOLAR_PROJ ECT_ADMIN in SAP Solution Manager to create a project (Project Administra-tion from menu). You will use this ABAP transaction for all documentation tasks described inchapter 4.1 through 4.4).

At first, it is just required that you create the Implementation Project and give it a meaningfultitle. Select the type Implementation Project (there is no special type for development pro-

jects but the implementation project type works fine). The solution may not be existing orknown at the early project phases. The solution information shall be entered as soon as it isknown. The information shall be available and up-to-date at the delivery of the BusinessBlueprint & Scope Check service. If you have a high level project description, you shouldupload this into the project description (optional).

Figure 1: Project Administration - Header Data Screen



11/53


4.1.1 Definit ion of Project Keywords

For each project, it is possible to define so-called project standards. In order to enable certainclassification tasks later on, it is necessary to define a set of keywords that will then be avail-able within your project. Therefore, you go to the Project Standards tab from the projectheader data screen, go into the sub-tab Keywords and click on the Project Template but-ton. This brings you to the edit mode (see Figure 2).

Figure 2: Project Template - Keyword Definition

At the end of the keywords list add the additional keywords as shown inTable 1.

Keyword NameCORE_PROC Core Business ProcessSAP SAP StandardSAP_EXT SAP with ExtensionSAP_MOD SAP with ModificationCUST Custom Development

Table 1: New Project Keywords

Then save the new defined keywords. You have to do this task only for the first project you

document as the project template data is available to all projects.

As the final step, you need to add the keywords to the project in order to make them availablefor this special project. This is done by selecting the keywords in the keyword directory(where you have previously added them) and move them over to the project by clicking thedouble left arrow button. This has to be done for each project that you document.



12/53


4.2 System and Application Landscape

To manage the development project and to operate the custom code later on, it is importantto know which applications are concerned. The application landscape contains the list ofsoftware product versions involved in this project. The system landscape contains the list oflogical components (placeholder for real physical systems independent of the system role likedevelopment, quality assurance or production) involved in this project. For understanding therealized business processes, it is essential to have the logical systems defined in the SystemLandscape tab. It is not required to have real existing systems already available. You cancreate new logical systems by just referring to the underlying product versions. After the realsystems are known, you need to add them also in the System Landscape tab according totheir role (see also chapter 4.3 Physical System Landscape).

Figure 3: Project Administration - System Landscape Screen

The creation of logical systems can be triggered out of the value help for the logical compo-nent or via the system landscape management application (transaction SMSY). You can alsouse existing logical components that have been defined earlier (e.g. during the definition of a

solution). The product version information value help that you get for selecting a logical com-ponent already contains all available product versions for software delivered by SAP. Theinformation is regularly updated via content updates into your SAP Solution Manager. Incases where a logical component requires additional product versions to be installed for thisproject, you need to list these product versions within the Additional Product Version De-



13/53


pendencies chapter within the document Application Components and Namespaces de-scribed in chapter 4.5.

If you are using other 3rd party or own software running outside any SAP system, you need todefine a custom product version in order to be able to specify it as part of your system land-scape. A logical component needs to be defined for each non-SAP system as well. As weneed to have the complete picture of all systems involved within your project we expect youto create custom product version entries for all such systems (see Figure 4). The product keyshall be defined in the customer namespace. If the product uses an own database systemthis shall be flagged in the components tab. The Technical Instance flag indicates that thisproduct does not provide any business logic but only technical functionality (e.g. a pure UIrenderer).

Figure 4: System Landscape - Maintain Custom Software Components

If your custom product is built using multiple independent software components, you shall

enter these as separate Main Instances. You can use these instances later to define busi-ness process steps to be executed on them.

In case your custom developed solution has inter-company interfaces, you also need to de-fine a logical component for the external endpoint of the interface. For such cases just defineany product name that represents the external endpoint (e.g. EXTERNAL VENDOR).



14/53


4.3 Physical System Landscape

As soon as real physical systems exist on which the solution is running, you need to enterthose into the system landscape shown above. In the early project phases, this will usually bedevelopment systems while in later stages the productive systems shall be added as well.

Therefore, the system list in the system landscape tab offers several system roles. Beforeyou can map physical systems to logical components, the physical systems need to beknown to the SAP Solution Manager. The most comfortable and recommended way to makesystems know to SAP Solution Manager is via a System Landscape Directory (SLD). Eachsystem shall be registered at an SLD and the SLD connected to SAP Solution Manager (ifmultiple SLDs are used they can be consolidated into one SLD that is connected to SAPSolution Manager). Each system known to this SLD can directly be found in SAP SolutionManager and can be used via the value help where systems can be entered. If you enter asystem for an already defined logical component you will only be offered by a selection ofsystems that match to the product version defined for the logical component.

For non-SAP systems, you have to define them manually - it is recommended to also do thisin an SLD and to connect it to SAP Solution Manager. If you have not setup an SLD for pro-viding the system information automatically, you may also create system definitions via dataretrieval from the transport management system (for ABAP systems) or manually via thecreation wizard out of the system landscape management transaction (SMSY LandscapeComponents right mouse click on Systems Create New System with Assistant) (seeFigure 5).

Figure 5: System Landscape Maintenance - System Creation Wizard



15/53


4.4 Solution Defini tion

For the minimum documentation of a development project, this chapter is optional and can beskipped. For managing the operational tasks to keep the business processes runningsmoothly you have to define a so-called Solution within SAP Solution Manager. A solutioncontains the physical system landscapes as well as the business process definitions to besupported by it. A solution may thus include business processes from multiple projects. Anew project also may fit into an already existing solution. In this case you should enter thesolution name into the project header (see Figure 6).

Figure 6: Project Header Data - Mapping to a Solut ion

For creation of a new solution you can use a wizard in the SAP Solution Manager work centerSystem Landscape Management (transaction SOLMAN_WORKCENTER) under Common

Tasks Create Solution (see Figure 7).

Figure 7: Solution Manager Work Center - System Landscape Management



16/53


4.5 Appl ication Components and Custom Namespaces

Besides the technical description of the product versions, you shall also define at least onecustom application component within the application component hierarchy to identify the cus-tom development application. This identification tag can then be reused in many places withinSAP Solution Manager (e.g. as an identifier in a problem message to link it to this customdevelopment).

The top level component name is the minimum requirement. For complex projects, it may beuseful to define sub-components for logically separated software parts as well.

The application component hierarchy as well as the list of custom namespaces defined forthe custom code shall be documented as a separate document to be uploaded into SAP So-lution Manager. You add this and other information (described in the later chapters of thisdocument) to the previously created project via transaction SOLAR01 (for maintaining busi-

ness blueprint information for a project). If there are multiple projects defined, you can selectthe project via the menu path Business Blueprint Other Project.

As mentioned already in chapter 4.2 System and Application Landscape, you shall docu-ment additional product version dependencies. This is necessary if there is more than oneproduct version required to be installed on a certain logical component (typically one or morerequired Add-ons). The dependencies shall be described in the chapter Additional ProductVersion Dependencies of the template Application Components and Namespaces. Thistemplate is available in the appendix of this document.

The documentation shall be uploaded at the project top level node into the Project Documen-tation tab using the name Application Components and Namespaces (see Figure 8 andFigure 9).

Figure 8: Project Documentation in Project Business Blueprint (SOLAR01)



17/53


Figure 9: Upload Documentation File

4.6 Business Scenario and Business Process Documenta-tion

It is important that a realized custom development is documented within the context of thebusiness processes where it is included. Business processes that belong to the same busi-ness scope shall be grouped into so-called business scenarios. Each business process isalways assigned to one business scenario. Multiple business processes of one project maybe assigned to the same business scenario. You may either define business scenarios andprocesses completely by yourself or start with a template scenario/process delivered by SAP.If you define the complete business scenario and business processes yourself from scratch,you can skip chapter 4.6.1.

4.6.1 Starting with an SAP delivered business scenario template

It is very typical that a custom development extends or modifies business processes that aredelivered with SAP standard applications. For SAP standard business scenarios and busi-ness processes, SAP delivers already a model and documentation inside the SAP businessprocess repository (BPR). For each business process that is involved within your project youshould try to find the closest SAP delivered business process model in BPR and copy it intoyour project documentation (see figure 10). This can be done in the Business Blueprint ofyour project. The SAP solution maps found under SAP Solution Maps help you to navigate tothe suiting business scenarios.

http://www.sap.com/industries/lifesciences/midsize/solutions/business_tools/index.epx?tab=tab1http://www.sap.com/industries/lifesciences/midsize/solutions/business_tools/index.epx?tab=tab1


18/53


Figure 10: Business Process Repository - Selection of Bus iness Scenarios / Processes

After you have selected the matching business scenario(s) and saved all SAP business youget the complete list of associated SAP standard business processes and have to deletethose that you do not touch within this project (see Figure 11).

Figure 11: Structured Documentation o f Bus iness Scenarios / Processes in Project



19/53


For each business process, you need to adjust the list of business process steps as well asthe association to your logical systems in order to match the business processes that yourdevelopment project will realize. For each additional logical business step that you realize viaown custom software, you shall add an additional business process step in the step list andgive it a name that briefly explains the business activity executed within this step.

4.6.2 Define missing business scenarios, processes and steps

Whether you have started using an SAP template or not you may need to add further busi-ness scenarios, business processes and business process steps to completely describe yourproject.

It is important that this business process documentation is understandable by somebody fromoutside who has good knowledge on the SAP business applications but has no knowledgeabout specific internals of your company (e.g. a service provider operating your system or an

SAP support engineer who delivers a support service.

Figure 12 provides a generic guideline for defining business scenarios, processes and steps.Besides this, it is important that each software activity that is executed on a separate logicalcomponent is also modeled as a separate business process step. If a business process stepthat is performed externally is important for understanding the whole business process, thisstep shall be modeled and assigned to a specific external logical component as well. Thesame is true for steps that are not executed by software but that are important for the process(e.g. a printed document has to be sent via post mail). You can also check out the SAP deliv-ered standard business process templates within the SAP business process repository formany examples showing you the expected documentation granularity.

Adding a new business scenario can be simply done in the Business Blueprint by adding a

reasonable name into the Structure tab at the Business Scenarios node of the project treeand save it. This will create a new sub-tree under Business Scenarios which you will use foradding business processes.



20/53


Figure 12: Scenario, process, step, transaction

To add a business process, you first select the Business Processes sub-node for the sce-nario where this process belongs to; add a reasonable name into the Structure tab, and saveit. This will create a new sub-node under the Business Processes node with the chosenname.

The scope of a business process step shall be the activity that executes a single logical stepwithin the business logic. This is not necessarily the use of a piece of software but may alsobe the manual execution of some task (e.g. copy a file from a CD shipped via post mail into a

special folder for further processing). For adding a business process step, you have to go tothe Structure tab of the business process and enter a reasonable name into the in the StepName column. The process step always needs to be assigned to a logical component. Thelogical component has to be defined beforehand as explained in chapter 4.2. If your businessprocesses get data from an external system, you should also define this external system as aseparate logical component and define a business process step on it.

Each business process step has to be classified into one of the categories listed in table 2 byassigning the respective keyword to it (as defined previously in section 4.1.1). The keywordscan be entered in the Administration tab of the business step within the sub-tab Keywords.With the Add button you get a selection list with the keywords that are assigned to the pro-

ject. In this list, you mark the appropriate key word (see Figure 13).



21/53


Keyword name / Category MeaningSAP Standard

The step is fully realized with SAP standardcode.

SAP with ExtensionThe step is realized with SAP standardcode with implemented custom extensions(e.g. BADI implementation).

SAP with Modification

The step is realized with SAP standardcode that was modified (i.e. some originalSAP program code in the SAP namespacewas changed).

Custom developmentThe step is realized with custom codewithin the custom namespace.

Table 2: Classification Types of Business Process Steps

Figure 13: Classify Business Process Step via Keyword

Whenever you modify the behavior of an SAP business process significantly via implement-

ing a standard extension hook (e.g. business add-in), you shall change the step classificationfrom SAP standard to SAP with extension.

For modifications of SAP business process steps via real modification of original SAP code,you shall change the step classification from SAP to SAP with modification. If the main



22/53


business activity originally performed by this step has also changed, this shall be reflected ina corresponding adjustment of the step name.

For most business processes and process steps, there exist templates in the Business Proc-ess Repository (BPR) of SAP Solution Manager. Whenever possible, you should use thesetemplates for documenting your enhancements. In case you do not find a well matching SAPbusiness process template, you have to create a new business scenario respectively busi-ness process from scratch. The minimum information required is at least which parts of thebusiness process are realized by the custom development or by SAP modifications as well aswhich business process steps are directly linked via standard SAP interfaces. Ideally, youshould document the whole business processes in which the custom development is inte-grated. As you will enter both types (customer and SAP steps) manually in this case, it isimportant to change the step class from Custom to SAP (respectively SAP with extensionor SAP with modification) for those steps that are original SAP.

It is important to understand which of the business processes are essential for your key busi-

nesses to work we call these processes the core business processes. A good indicator fora core business process is that you immediately would loose business or your logistics orproduction chain would be broken if this process is not available. A typical non core businessprocess would be one that produces statistical data for reporting. You shall identify your corebusiness processes by attaching the keyword Core Business Process to them. This can bedone from the Administration tab of the business process in the very same way as the clas-sification for business process steps was done.

4.7 Interface Documentation

The next task is to document the SAP interfaces that are used within the business processes.You shall enter at least all interfaces that are used from custom coding. In order to do so, you

shall use the Interface Documentation template document available in the appendix of thispaper. For each interface, please enter the technology type, technical name and performanceand volume KPIs. In order to map the interfaces to the business process steps where theyare used, you also need to enter the source and destination step name.

4.8 Documentation of Background Jobs

Background jobs are typically used to handle mass data processing without direct interactionwith users. You shall document all background jobs used in your project. A background jobshall be either entered directly at the business process step which the job realizes or on busi-ness process level at the business process that the job is part of. Go to the J ob Documenta-tion (see Figure 14) view in the J ob Management work center and execute the common task

Create J ob Documentation (see Figure 15) to create the job documentation.

The minimum information that shall be entered is the job name (as it can be found in the jobscheduler). If you already know which scheduler is used, you can choose between RedwoodCronacle and the ABAP job scheduler (BC-XBP). If you dont know that yet, choose BC-XBPas scheduler. You need to define at least one job step via Add. In the job step details, you



23/53


have to enter a description text of the executed program, the program type (ABAP report, anyexternal program or shell script or a command defined in the ABAP external command listSM69) and the technical name of the program it executes (e.g. ABAP report, executable pro-gram, shell script name).

In order to map the job to the business process documentation of the project you need to fillin the job name into the job table within the attachedJ ob List template document available inthe appendix of this paper and specify the business process step where this background jobis executed.

Use the System Landscape tab to specify the logical component where the background jobwill be executed. If you have already defined a solution into that you have copied the busi-ness processes from this project, you should directly enter the business process step withinthe solution where the job is executed.

If available, enter scheduling details, preconditions and limitations (e.g. dependency on otherjobs, not in parallel with other jobs), error handling procedures (what to do if job aborts, whatif it did not start or finishes too late) via the respective tabs, as well.

The detailed description of the business functionality shall be described additionally within thefunctional documentation document of the business process step where the job is mapped to(see 4.12),

Figure 14: Background Job Documentation Overview Screen



24/53


Figure 15: Background Job Detail Documentation Screen

In the early phases of the project, you may not have all information ready for the completebackground job documentation (e.g. responsible persons for monitoring or error handling maynot be defined during the implementation phase). In such cases, you shall add the missinginformation as soon as they are known.

4.9 Transactions and User Entry Points

Business process steps may be invoked by different means. They may be executed auto-matically by the system as a successor of a previous step (invoked via an interface), theymay be executed as a scheduled background job, or an end user invokes them. The inter-

faces and background jobs have already been documented in the previous sections. Thissection covers the end user invocations.

Therefore you shall document for each business process step which may be invoked manu-ally by an end user the software entry points that the end user can use to do so. Such entrypoints may be ABAP transactions, WebDynpro applications, Business Server Pages, anyURLs, programs etc. For entering this information, the separate tab named Transaction shallbe used at business process step level (see Figure 16). If there are multiple possibilities tostart the business process step (e.g. multiple transactions that can be used to perform thesame business function), you shall enter each of these entry points separately.

Select the type of the user entry point, the logical system where it is executed (usually thesame that is used for the corresponding business process step) and the technical name ofthe entry point. The In Scope flag can be used to distinguish entry points that will be handledwithin this project or not. It is not used for minimum documentation and we recommend onlydocumenting those that are in scope and therefore always mark that checkbox. The Stan-dard radio button allows identifying one entry point that will be automatically executed whenthe Execute button at the process step in the project tree is clicked. We recommend choos-ing the one that is supposed to be the most heavily used or most important one.



25/53


In case you have already assigned a physical system to the logical system, you can chosethe technical object name from a value help directly filled from the system otherwise youwill get a warning message that the object name cannot be verified.

For URLs, you can use placeholders for hostnames and port numbers if those are not yetknown (e.g. http://:/application).

Figure 16: Documentation of Transactions / User Entry Points

4.10 Performance and Volume KPIs

For all core business processes expected volume figures shall be documented. This includesexpected number of executions or per time unit, number of documents created, and number

of concurrent users. It also includes expectations for maximum and average response timesexpected for certain business processes or single business process steps.

You shall enter the expected volume figures at least for each core business process. If possi-ble you should provide these figures at business process step level. For documenting thisinformation you shall use the Performance and Volume KPIs template available in the ap-pendix of this paper. The completed document has to be uploaded into the Project Documen-tation tab at the structural element where it belongs to (project, business scenario, businessprocess, process step).

4.11 Development object list for Custom Development orCustomizing Objects

All development objects that are newly created or modified within your project shall be docu-mented within the development tab either on business scenario, on business process, or onbusiness process step level. We recommend that you create separate development pack-ages in the customer name space for each logical development. For modified SAP code youshall enter separate transport requests containing exactly the list of modified SAP objects.



26/53


Note that the Development tab is only available in the Configuration project phase and notin the Business Blueprint phase. From the project maintenance transactions (SOLAR01 forbusiness blueprint and SOLAR02 for configuration) you can always switch to the other onevia the menu path Environment Business Blueprint / Configuration. We highly recommendthat you specify the packages respectively transport request object lists as closely as possi-ble to the element in the hierarchy tree where the included development objects really belongto. If certain development objects are generic ones used in various steps of a business proc-ess or in all business processes of a business scenario, they should be put into a packagerespectively transport request on business process or business scenario level. The closeryou can map development objects to business steps or processes, the more precisely it ispossible to tell you which processes or steps may be affected by planned software change.

Similar to documenting the development objects, you shall also document the business cus-tomizing objects. Therefore the Configuration tab shall be used. The configuration objectsshould be put into separate BC sets respectively dedicated customizing transport requests.

Those BC sets and customizing transport requests shall also be added in the Configuration

tab as precisely as possible to the related business process or business process step.

In order to add a software package name, a BC set or a transport request you should have alogical system with a physical assignment of the corresponding development system in place.Also the connectivity from the Solution Manager system to this development system shouldbe set up. This allows you directly accessing the object repositories on the development sys-tems and put the references into Solution Manager.

We highly recommend that you manage all your transports via a centralized transport man-agement system. This can be setup within the Solution Manager itself or in any other SAPWeb Application Server system. If the central transport management system is not part of thesolution which is used by your project, then you have to add a logical and physical systeminto your solution landscape so that you can select the transport requests from there. In case

you have no centralized transport management (not recommended) then you can also fetchtransport requests from each system within your solution landscape (precondition: the physi-cal systems and their connectivity have been defined in SAP Solution Manager).

It is very typical that the list of development objects grows during the development phase. Ifyou already have the packages for the logical units in the beginning you should reuse them toadd further developments inside and thus need not change the documentation within theSolution Manager project. You are also not required to add all objects into one single requestbut you can define multiple transport requests in each development tab.



27/53


Figure 17: Transport Request Documentation

4.12 Functional Documentation / Business Background

In order to understand the functionality that is realized by the custom code development, it isimportant that you provide additional textual information explaining the following topics:

Business background information:

What are the business reasons why this project was initiated? Which gaps of the SAP stan-dard solutions have been identified that shall be closed by this project? Keep in mind that thisdocumentation shall be understandable not only by the business persons from the customerbut also by people not familiar with the customers organization. This information shall bedocumented on project level.

Business gaps closed

Which gaps of the SAP standard solutions have been identified that shall be closed by thisproject? If internal organizational preconditions at the customer are necessary to understandthe business requirements, these need to be documented as well. This information shall bedocumented either on project level or per business process scenario, process or step.

Functionality

What are the functions realized? For business process steps that contain modifications ofSAP code, you shall document why this modification is required, which alternative modifica-tion-free options have been investigated and when this modification has been signed off bywhich person. For business process steps with extensions of the SAP standard, you shall

explain what the extension functionally does. All this textual information shall be added in theProject Documentation tab at the structural element where it belongs to (project, businessscenario, business process, or business process step) (see Figure 18). A Functional Docu-mentationtemplate is available in the appendix of this paper.



28/53


Figure 18: Add textual documentation

4.13 Integration and Volume Test Plan Documentation

It shall be documented within one document on project level how you plan to setup and exe-cute integration and volume tests that cover all business processes and all software compo-nents involved in the business processes of the project. You should also document the solu-tion and the system landscape roles to be used for the tests. The technical solution shall bemaintained within SAP Solution Manager in the system landscape information (typically astest system role). For the volume tests, you should document how these volume tests will beprepared and executed (e.g. test data preparation, real users with scripts or automated usersimulation, ramp-up profile). Also clarify how much load you plan to produce during the testsand how this load is distributed on the business processes. Include also the volume testing ofyour background jobs in this documentation.

Describe how many of those tests with which time interval in between are planned and howyou measure the results (have errors occurred, what was the concurrent user number andthe corresponding response times, what was the system load over time on each system, howmany documents have been processed in which time frame).

All information shall be documented using theTest Plan Documentation template available inthe appendix of this paper.

4.14 Appl ication Operations Guide

The Application Operations Guide has to be provided by the development project team. Itcontains information on how the developed application can be operated. From the Application

Operations Guide an Operations Handbook shall be derived that will be used by the opera-tions team describing the operations tasks that need to be performed during the real opera-tion of the solution.

Information to be provided in the Application Operations Guide:



29/53


Monitoring of the application (business process level as well as technical level). Howto detect problems respectively avoid critical situations or performance problems.

How to monitor data growth. Support tools and troubleshooting guidelines for analyzing problem situations. How to

find the root cause of problem situations. How to analyze performance problems.

Consistency checking. How to verify data consistency (if replicated data exists). Howto safely repair potential data inconsistencies.

Management of the application. How to start/stop the complete application. How tochange configuration. Administration tools to be used. How to backup and restore thecomplete solution. Regular tasks to be scheduled and monitored (automated back-ground jobs as well as manual tasks).

Scalability and high availability. How to scale up the solution for higher user or datavolume. How to setup a high availability scenario.

Transport and change management. How perform software changes on the completesolution and how to integrate all components into the one transport order concept.

Remote supportability. How to setup safe remote access to all support relevant tools(e.g. special user roles for read only access permission, URLs to support tools).

This information shall be documented using the Application Operations Guide template avail-able in the appendix of this paper.



30/53


5 Appendix

5.1 Template: Appl ication Components and Namespaces

About this TemplateYou use this template to document the application component hierarchy for your develop-ment. These component names can be used in Solution Manager Service Center to assignincidents to development areas. SAP also maintains an application component hierarchy forall its delivered software components. If your custom development was delivered by SAPcustom development your component hierarchy may have already been included within theSAP component hierarchy. Otherwise you have to define it by yourself in the customername space.Additionally this template shall be used to documents development name spaces that wereused to keep all development objects under the same prefix. We recommend to request a

name space from SAP (viahttps://service.sap.com/support

Keys & Requests

Development Namespaces) instead of using the generally reserved customer name spaces(Z* and Y*). Beside making it more easy for you to distinguish different projects objectsdoing so it also simplifies the potential need of merging different companies SAP systems.Application components should be typically created per SAP product which they extend andper business scenario. For very simple projects you may define even only one applicationcomponent.Namespaces are typically created per SAP product. You would typically use just onenamespace per SAP product where you develop custom code in.

1. Application Components

List all application components that you have defined for your custom development and mapit to the associated product, business scenario and eventually business process by filling thetable below. If you defined hierarchically structured components then list all elements in thecomponent tree with their mapping.

Application Component Related area (project, product, business scenario)

(e.g. XX-PROJ -ABC)) (e.g. Project ABC)

https://service.sap.com/supporthttps://service.sap.com/support


31/53


2. Development Namespaces

List all namespaces that you have defined for your custom development and map it to theassociated product and eventually business scenario and eventually business process byfilling the table below.

Development Namespace Related area (project, product, business scenario)

/CFCRMX2/ (e.g. Project ABC, product CRM)

3. Addit ional Product Version Dependencies

You have already documented the list of logical components and the product versions thatthey are based on within Solution Manager for your project. In cases where your project re-quires additional products to be installed on those logical components you need to list theserequired product versions in the following table. This is necessary because the Solution Man-ager based landscape model allows only one product version being associated to a logicalcomponent.

Logical componentname

Product versionname

App. Server Type Description whyneeded



32/53


5.2 Template: Interface Documentation

About this TemplateYou use this template to document the SAP interfaces used within custom code as well asthe cross system interfaces between custom code steps. You have to identify the interfaceby its type and technical name as well as to link it to the business process and businessprocess steps between which it is used. A short description shall be given explaining theinformation exchanged via each interface. You shall also provide information about ex-pected document volumes and expected throughput.

1. Business scenario:

Copy this chapter if you need to distinguish multiple business scenarios (unprotect the docu-ment before copy and re-protect afterwards).

1.1 Business Process:

In order to get the value help available for the interface types you need to protect the docu-ment via ToolsProtect Document).Copy this chapter if you need to distinguish multiple business processes (unprotect the docu-ment before copy and re-protect afterwards). If you need more lines in the interfaces tableunprotect the sheet and copy lines (via mark - copy - paste) then re-protect again.

Nr. Name of businessprocess sourcestep

Name of businessprocess destinationstep

Interface type(if not XI based)

Interface type(if XI based)

Mode(sync/async)

1,2,3,4,5,



33/53


1.1.1 Details on Interface Nr.

Copy this chapter if you need to document multiple interfaces for this business process.

Technical information:

Attribute Value

Technical interface ob-ject name

(e.g. IDOC message type, called transactions, program name, func-tion module, workflow task name)

Routing information(e.g. RFC destination, server group, logon group, J MS queue name,URL, ICF path, qRFC queue name, XI/PI scenario name)

Description of data ex-changed /business objects

(e.g. purchase requisitions)

Document volume related to this interface (fill in the information you know):

Attribute Value

Average number of documents per hourMaximum number of documents per hourAverage number of documents per dayMaximum number of documents per dayAverage number of documents per weekMaximum number of documents per weekAverage number of documents per monthMaximum number of documents per monthPerformance KPI (in ms)



34/53


5.3 Template: Job List

About this TemplateYou use this template to document the list of background jobs used within this project. Use thejob names that are also used within the Solution Managers J ob Documentation applicationwhere you have documented further details about these jobs. Enter the business scenario,business process and business process step names within this project where the background

job is executed. If the same job is executed in multiple business steps you have to enter itmultiple times here also.

1 Background Jobs

The job names need to be identical to the job names entered in the Solution Manager J obDocumentation application. This table is used to map the jobs to the corresponding businessprocess steps within the project.

J ob Name Business scenario Business process Business process step



35/53


5.4 Template: Performance and Volume KPIs

About this TemplateYou use this template to document the expected document volumes to be processed by thiscustom development. Also document the number of concurrent users expected to executethis custom development. If performance expectations exist they shall also be documentedin here (e.g. number of documents to be processed per time unit or maximum duration ofcertain business process steps). If possible provide this information per business process oreven per business process step.

1 Performance / Usage KPIs

Enter one line for each KPI that you want to specify. Each KPI shall be mapped to a specificend user action which is defined by the entry point of the user (transaction / program heworks with e.g. order entry VA01) and the action inside within this program (e.g. save or-der).

Transac-tion / Entrypoint

Action Peakhour(0-23)

Max execper hour

Avg. execper hour

ConcurrentUsers

Required typi-cal responsetime (sec)

Measureresponsetime (sec)

2 Document Volume

Enter one line per document type that is processed in your project with a significant volume tobe documented.

accessed/transferred objectsDocument type(technicalname)

Description New objectsper month max / hour avg. / hour max / day avg. / day



36/53


5.5 Template: Functional Documentation

About this TemplateYou use this template to document the business background that led to this custom devel-opment. Explain what are the functional business gaps closed by this development.Describe on business process level how this development logically works. The explanationshall refer to the business process and step names that were also used within the businessprocess structures that you have documented within the project in Solution Manager. For allbusiness process steps that are of type Custom development, SAP with enhancement orSAP modification a description of their functionality is required. For SAP enhancements theimplemented SAP enhancement objects (e.g. BADIs) shall be listed. For SAP modificationsit shall be explicitly explained which modification free alternatives have been evaluated, whythe modification option was chosen in the end and who on customer side has officiallysigned off the modification. Additionally it has to be documented which preconditions (e.g.

certain SAP releases or functionalities) or assumptions are made that have to be met for thedeveloped to functionality to work.

1 Glossary

Here you may provide a glossary for the abbreviations that you within this document or withinthe business process / step names (e.g. PR =purchase requisition).

Term Definition

2 Business Requirements / Gaps to be Closed

Explain why this custom development was needed. Which functionality was missing in theexisting SAP software?

3 Functional Documentation

Explain how the functionality is realized by the custom code on a logical level. The documen-tation should be structured by business processes using the same names as in the business

process structure within the project in Solution Manager. The process step names from theproject documentation should be also used within the functional documentation to have aclear relation. You may also export the business process graphics out of Solution Managerand include it as a picture in here.



37/53


3.1 Business Process:

Provide the documentation for this business process. Describe step by step for each nonSAP standard step what it does and how it is triggered (user interaction, synchro-nous/asynchronous communication of predecessor step, background job) respectively how itinteracts with its successor(s).

3.1.1 SAP enhancements

Only enhancements that are not trivial or perform some unusual business functionality arerequested to be separately listed here. Otherwise

Explain briefly what this enhancement logically does. If you have multiple modifications then

copy this chapter for each of them.

3.1.2 SAP modifications

As modifications to SAP standard code may have dangerous effects to other areas and alsomay lead to additional maintenance costs in the future it is important to have more detaileddocumentation for them. If you have multiple modifications then copy this chapter for each ofthem.

Logical description of the modification:

Describe what functionality was modified in which logical way.

Alternatives evaluated:

Explain briefly the alternatives you were taking into account.

Final reason for choosing the modification alternative:

Why did you finally decide to implement this modification instead of any other alterna-tive?

Responsible person at customer who signed off for this modification:

Who officially agreed from customer side to implement the modification? This may bealso a sign off committee.

3.2 Precondi tions / Assumptions

Explain what is required for this development to work (e.g. expected releases or functional-ities of SAP products).



38/53


5.6 Template: Test Plan Documentation

About this TemplateYou use this template to document how the testing of this project will be organized. Thedocument is organized as a type of questionnaire.

This document contains form elements to simplify the data entry but it requires being in pro-tected mode in order to enable the form entry.

Roles and Responsibil ities for TestingAction:Please enter information about Test Management roles and responsibilities andprovide us with the contact details of the persons in these roles.

Example:

Role / Area Responsible Company Phone e-Mail

Business Process Owner(s)J ohn SmithKlausMustermann

XYZ GmbHXYZ GmbH

+49(1)777-888+49(1)888-777

[email protected]@xyz.com

Roles

Role / Area Responsible Company Phone e-Mail

Executive Sponsor

Test Project Manager(s) /Test Coordinator(s)Application implementation/ operationTechnical implementation /

operationBusiness Process Owner(s)

Key / Power User(s)

Test Case Development

mailto:[email protected]:[email protected]:[email protected]:[email protected]


39/53


Transport Landscape

Please describe the transport landscape of the chosen solution in the tables below.Action : In this table please enter the information regarding productive system in thelandscape.

Example:

SID1

System role Release

PRD R/3 system, Automotive 4.7 SR 2

Productive system

SID System role Release

Action : In this table please enter the information about each system in the transportlandscape. This includes the SID of the upstream 2- and downstream -3 systems for eachsystem in the landscape.

As soon as the table is completed, it describes the whole transport landscape and the trans-port routes in the landscape.

Example: the table below describes the classical 3-systems landscape DEV 4 ->QAS 5 ->PRD

6. Here PRD is a downstream-system for QAS and DEV is upstream-system for QAS:

SID Role in the transport landscapeSID of up -stream -system

SID ofdown-stream -system

DEV Development system - QASQAS Quality Assurance system DEV PRDPRD Productive system QAS -

1SID System ID. The name for your SAP system which is unique throughout your organization and

must consist of exactly three alphanumeric characters where only uppercase letters are allowed and thefirst character is a letter (not a digit)2Upstream-system means a system where the transports come from3Downstream-system means a system where the transports go to4DEV development system in a transport landscape5QAS quality assurance system in a transport landscape


6PRD productive system in a transport landscape



40/53


Systems in Transport Landscape

SID Role in the transport landscapeSID of up -stream -system

SID ofdown-stream -system

Roles, Responsibili ties and WorkflowAction:In the column Project, Name and Role please describe who is responsible foreach particular step in the change management and the corresponding role. If they are differ-ent for several projects please enter the information for each project in one field using a pro-

ject short name as a prefix.

Example:

Step / Function Project, Name and Role

Perform functional test in DEV PSAP_R3 - J .Smith, Test Manager;SCM_SAP - S.J ohn, Test Manager

Roles in Change Management

Step / Function Project, Name and Role

Decision about software projects Create and assign transport requeststo developers

Plan functional test in DEV Perform functional test in DEV Transport into QAS Monitor result of import in QAS Plan test in QAS Perform test in QAS Approval of test Import into PRD Monitor result of import in PRD

An exception to the standard transport workflow could be necessary to allow fast reaction tourgent problems in the productive system.

Action :Please answer the question:



41/53


Exceptions

Questions AnswersIs there an exception to thisworkflow allowed (e.g. foremergency transports)?

Yes No

Who can request those emergencytransports?

End User

Key User

Business Process Owner

System Owner (Administrator)

Development

Who is responsible for approval ofemergency transports?

Key User

Business Process Owner

System Owner (Administrator)Development Manager

Change requestAction: Please mark the appropriate field if there is any standard change request formin use in the company and if there is a change request database storing the requests, whichare already processed.

Change Request Form and Database

Questions Answers

Change request form available? YesNo

Change request database available?Yes

No

Current Test Strategy

Activi ties distr ibut ionAction :Please use the tables below for each test type to describe how the test activi-ties are assigned to organizational units in the company. We are interested in the followingtest types: Unit Test7, User Acceptance Test8, Customer Development Test9, Integration Test10,


7Unit Test the lowest level of testing where the program or transaction is tested and evaluated forerrors



42/53


Regression Test11

and Technical System Test12

. Inside of each table for each activity,please mark the appropriate organizational units (one or more) which are responsible for thisparticular activity. If there are any comments or additions regarding activities distributionplease use the field under the table. In each table for each activity mark at least one respon-sible organizational unit.

Unit Test Who performs an activity?

Act iv it ies

EveryBusinessDepart-ment ontheir own

CentralTest or-ganizationin eachbranch

CentralTest or-ganizationcorporatewide

CentralIT de-part-ment

Projectteam

to decide what needs to be tested

to create test case descriptions

to organize testing

to execute test

to monitor test

to evaluate test results

Comment to the table:

8User Acceptance Test represents end-to-end testing from the business perspective. The purpose ofthat is to prove that initial business requirements were implemented exactly and in accordance to speci-fications made before9Customer Development Test mixture of Unit Test and Integration Test with scope limited to the cus-tomers own development10Integration Test is accomplished through the execution of predefined business flows, or scenarios,that emulate how the system will run your business. Integration Test starts with the testing of the cross-functional integration points and ends with the end-to-end testing of critical business processes11Regression Test test of critical business processes after a change to ensure that a) any problemhas been fixed and that no other previously working functionality has been harmed as a result of thechanges and/or b) that newly added features working as designed and have not created any unex-

pected side effects


12Technical System Test test aimed to verify the production system environment from a technicalstandpoint, e.g. to test if the system can be started / stopped properly, if the basis technical infrastruc-ture is working fine and the whole system in conjunction with database and operating system performswell from technical point of view. Among this the following technical tests are usually part of TechnicalSystem Test: backup and recovery, system administration, printing and faxing, failure scenarios, disas-ter recovery



43/53


Definition of test scope

Act ion:Please use the table below to let us know about how you evaluate which test cases areneeded for specific software changes and software maintenance. In other words, which methods andstrategies are in use to help in decision of which test cases should be executed after a change of aspecific type?

Test Scope

Change type

Possible methods projects regularmaintenance

hot fixprocess

General regression testing of all core business processes

Analysis of changed / new objects and affected application area

Evaluation of customizing settings to identfy which processes areconfigured and therefore most likely used and potentially affected bychangesEvaluation of load profile (e.g. EWA

13, ST14, RBE14, etc.) to find the

business processes with a high load (meaning that such processescould also be most critical for everyday work)

Only new functionality will be tested, usually no Regression Testing

Others:

13EWA Early Watch Alert


14RBE - Reverse Business Engineer - a tool used for process-oriented analysis and continual optimiza-tion of SAP production systems. Using data from production systems it is possible to analyze how func-tions in the SAP System are used and identify potential for improvement



44/53


Development of tests

Action:Please use the table below to specify who is responsible for developing of testcases. Please also specify what kind of testing is meant (manual or automated).

Development responsibili ty

Options Manual

Automated

Remarks

Every Business Department on its own

Specific project team (implementation /upgrade / etc.)

Central Test Organization in eachbranch

Central Test Organization corporatewide

Central IT department

Test Case descript ionAction :Please use the table below to specify what information is included in the stan-dard test case description adopted to use in the company.

Information in Test Case description

Information Available Remarks

Test Case ID (unique identfier)

Name of Project

Name of Business Process

Owner of Test Case

Test Type (e.g. Unit, Integration, Regression)

Test System

Client

Detailed description of preparation activities

Detailed description of test procedure

Check / Expected Test Results

Only for Integration Testing: dependencies onother test cases (predecessor and successor)



45/53


Customer specific quality targets and criteria

Completeness of any test plays an important role in the total success of the test. A completetest of a complex business scenario very often cannot be created without participation of thepeople who deal with the scenario in their day-to-day work. As the major goal of any testactivity is to get reliable results, a controlling of correctness, completeness and grade of detailis very important.Action :Please answer the questions below.Quality targets and criteria

Questions Yes No Remark

Is the 2-person policy in use, i.e. test casesneed to be tested twice by 2 different persons?

Are there some customer specific quality targetsor criteria?

Which?

Are there some special requirements regardingdocumentation of test cases (paper orelectronic)

Which?

Are there some legal requirements affecting thetest process?

Which?

Is there a person controlling the completenessof the tests?

Who is this person?

Is there a person controlling the correctness ofthe tests?

Who is this person?

Is there a person controlling the grade of detail

of the tests?

Who is this person?

Do you use templates for test case creation?Example?

Test result documentationAction :Please answer the questions below.Handling of Test Results

Question Yes No Remark

Do you document the results of the manual testing? How?

Do the currently used tools allow the tester to documentthe test results (results such as what has been tested bywhom, when and with which results)



46/53


Information in Test Result Documentation

Action :Please use the table below to specify what information is included in the stan-dard test result documentation adopted to use in the company.

Information in Test Result Documentation

Information Available

Remarks

Name of Tester

Master Data

Transactional Data

Actual Test results

Status information

Remarks

Signature

Date of Test

Test KPIsAction:Please mark in the table below what kind of measurements regarding reliabilityof the tests via predefined KPIs

15 you have.

Test KPIs

Possible measurement Yes No Remark

General Stability

Availability / unplanned downtime

Performance

No. of short dumps

No. of update-errors

No. of trouble tickets (per component)

Interface throughput


15KPI - key performance indicator - a measurement or metric for evaluating a company's business strat-egy, performance, or technology. KPI express abstract company objectives in financial or physical unitsfor comparative purposes



47/53


Test data preparation and management

Action:Please describe what methods you use to prepare the data in QA system data-base before testing.

Test Data Preparation

Possible method Yes No Remarks

Refresh via system copy o f PRD

Refresh via client copy from PRD

Refresh via client copy from a standard client in QAS

Manual creation of master data

Automated creation of master data

Manual creation of transaction data

Automated creation of transaction data

Test Data ManagementAction:Please describe what methods you use to manage the test data (to create it, tostore it, to update it, etc.) for testing.

Test Data Management

Possible method Yes No Remarks

Microsoft Office Excel spreadsheets

Local or central test data databases What kind of databases?

Paper

Automated Test Tools

Test data is not managed centrally and is up to atester



48/53


Test execution

ExecutionAction :Please answer the questions below.Execution: Manual or Automated?


Do you use manual testing in your current testapproach?

Do you use automated testing in your current testapproach?

How?

What part (percentage) of the total testing do you

perform manually?

MonitoringAction :Please answer the questions below.Monitoring


Does the current test approach allow you to have aclear picture of the testing progress at every point oftime?

Does the current test approach allow you to estimatewhether the time schedule is going to be kept?

Does the current test approach allow you to have anoverview of the actual test results?

Does the current test approach allow you to react asrequired in case of error?



49/53


Error Tracking

Action :Please describe the workflow for error tracking established in the company.Error Tracking

Questions Answers

Who is involved in case of an error during tests in QAS?

Do you have a defined process in case of test errors (feedbackloop / issue tracking) ?

Yes No

How does the workflow look like to correct these errors?

ToolsAction :Please answer the questions below.Tools


Do you use CATT16 / eCATT

17 for testing?

Are there any 3rd

party tools involved in your currenttest approach?

Are there any tools used for assignment of testers?

Are there any tools used for execution of tests anddocumentation of results?

Are there any tools used to follow-up in case of error?

Are there any tools used to manage test data?

16CATT -Computer Aided Test Tool - an SAP tool enabling you to combine and automate businessprocesses as repeatable test procedures


17eCATT - extended CATT - a successor of SAP CATT which provides more flexibility and functionality.Delivered starting with the basis release 6.20 of the SAP Web AS



50/53


5.7 Template: Appl ication Operations Guide

About this TemplateYou use this template to document what needs to be known in order to smoothly operatethis custom developed component. The major topics to be described are: monitoring, ad-ministration, software change management, high availability and troubleshooting. It de-scribes which tasks to be executed and which tools to be used.

This document does not replace the Operations Handbook in which the customer respec-tively the operations organization has documented the concrete tasks, involved parties andinteraction procedures. It is rather the basis for defining the Operations Handbook.

1 Monitoring

Monitoring is the task of retrieving information on the status of a certain component, businessprocess or process step that is relevant for the smooth functionality of your implementedbusiness processes. This chapter shall be used to describe all tasks and tools that are re-quired to find out about any critical situation that indicates an existing or arising disturbanceor failure of an implemented business process.

1.1 Alert Monitoring

Describe here whether there is integration into alert monitoring tools (e.g. SAP CCMS) isavailable and which alerts will be propagated. Explain which alerts have to be checked andwhat there meaning to the business is. Also provide recommendations on thresholds to bedefined.

1.2 Error Logs

Document which error logs are used by your components to report error situations and howto filter on them (e.g. application log object names or development locations or error mes-sages). You should also provide a list of all critical error messages with typical reasons andcorrective measures.

1.3 Workload Monitoring

Document how the workload produced by the custom development can be identified andmeasured. For ABAP based components this may be done via the default ABAP workloadmonitor by providing the filter information to identify the custom components (e.g. namespaceprefixes).

1.4 Interface Monitoring

For all interfaces that your custom development components are using document how tomonitor it for errors, throughput, delays, queues. If you are using SAP standard interfacetechnologies you just have to explain how to filter for your interfaces within the SAP standardmonitors. Also explain if possible how to distinguish the loa

solman confguration.pdf

Documents