Solution Documentation
2011 SAP AG
Page 1 of 67
Table of Content
1 2 3
3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2
Management Summary ........................................................................ 4 Application Lifecycle Management..................................................... 7 Solution Documentation Introduction .............................................. 10
Solution documentation definition.................................................................. 10 Technical landscape documentation basic content and roles ..................... 11 Business process documentation basic content and roles.......................... 11 What are core and mission critical business processes? ............................... 12 Business process structure 3-level hierarchy ................................................ 13 Solution documentation lifecycle ................................................................... 14 Main use cases initial and re-documentation .............................................. 15 Solution documentation benefits ................................................................... 15
4
4.1 4.1.1 4.1.2 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.3.3 4.4 4.5 4.5.1 4.5.2 4.5.3 4.6 4.6.1 4.6.2 4.6.3 4.6.4 4.6.5
2011 SAP AG
Page 2 of 67
4.6.6 4.6.7
Use case test management........................................................................... 46 Solution documentation assistant data sources and recommended data flow ................................................................................ 48
5
5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5
6
6.1 6.2 6.3 6.4 6.5 6.5.1 6.5.2 6.6 6.7 6.8
Appendix ............................................................................................. 60
Process components of projects and solutions.............................................. 60 Solution ......................................................................................................... 61 System components of a solution.................................................................. 61 Technical environment needed for data collection EWA / ST-PI ................. 62 Solution documentation assistant .................................................................. 63 Solution documentation assistant - definition................................................. 63 Solution documentation assistant - technical prerequisites............................ 63 Project to solution important transactions and work centres ....................... 64 Project preparation ........................................................................................ 65 Important links to more detailed information .................................................. 66
2011 SAP AG
Page 3 of 67
1 Management Summary
As solution landscapes are maintained and adapted to meet business demands, planning and reporting of the respective initiatives and projects become a fundamental instrument for successful solution operations. Efficient planning, reporting and operations require a clear and reliable documentation of the existing customer solution. This is the focus of the solution documentation standard. Its goal is to centrally document and relate business processes and technical information of SAP and non-SAP solutions, ensuring transparency, costefficient maintenance, and internal collaboration as well with SAP. This standard is intended as a starting point in the work with projects and solutions showing typical use cases along the application lifecycle. It lays a specific focus on the redocumentation use case. Though the technical landscape documentation is part of the solution documentation as well, it is treated as given and therefore explained less detailed. The standard solution documentation for custom development gives step by step guidance how to do solution documentation for custom developments. There are several more use cases covered than those shown in this standard. For instance, the details of template management and project implementation are extensive processes themselves, and therefore covered by separate documents. Consisting of technical landscape and business process documentation, solution documentation is the basis for all other SAP Solution Manager capabilities (see figure 1.1). This deep integration and reuse of business and IT information along the application lifecycle is the biggest advantage and the unique selling point of SAP Solution Manager. Solution documentation describes a customers technical components (SAP and non-SAP), his core business processes, and interfaces. It includes custom code/modification documentation, and links to supporting technical objects, like transactions and programs.
Figure 1.1: The system information and business process information maintained through solution documentation lies the foundation for all application lifecycle management processes shown in this figure. The correct usage of implementation projects automatically leads to sufficient solution documentation in the operations and optimization phase. If you start with the documentation in the operations phase, you should re-document your core business processes in SAP SAP Standard Solution Documentation Version: 2.0
2011 SAP AG
Page 4 of 67
Solution Manager (see figure 1.2). As a result, in relation to a complete implementation project only a subset of information is needed. Solution documentation can be continuously enriched along the ALM lifecycle phases: Design: Create global business process templates and specifications, e.g. for later roll-out of regional implementation projects Design/Build: Newly create or locally adjust business process structures during your regional implementation project Build/Test: Extend business process documentation during solution configuration, e.g. with custom code documentation, configuration information, test cases Operate: Re-document or adjust your business process documentation during operations, e.g. with system information; adjust process documentation after go-live Optimize: Verify your business process documentation before upgrades, e.g. delete obsolete information, such as not used custom code
Figure 1.2: Solution documentation focus areas Solution documentation functions as basis for the whole application management lifecycle. It ensures that customers achieve transparency of their IT solution landscape and business processes. Moreover, it fully exploits the potential of SAP Enterprise Support. Figure 1.3.lists customers typical solution documentation pain points and the SAP Solution Manager offerings solving those.
2011 SAP AG
Page 5 of 67
Figure 1.3: Solution documentation - typical pain points and SAP Solution Manager benefits The solution documentation standard provides you with best practice for set-up and usage of your own (re-) documentation. Readers will learn which documentation of customer solutions is urgently required and how this information can be gathered. The best documentation becomes worthless if it is not regularly updated. SAP Solution Manager provides the capabilities allowing a cost efficient and controlled update of your solution documentation. The main solution documentation capabilities are: System Landscape Maintenance/Directory (SMSY/SLD) Business Blueprint Solution Configuration Solution Documentation Assistant
Chapter 2 of this document provides a general overview of application lifecycle management and SAPs standards for end-to-end (E2E) solution operations. Chapter 3 gives an introduction into the topic solution documentation and clarifies the basic definitions. Chapter 4 explains how to implement the standard. The technical landscape documentation is part of the solution documentation, but already well documented in the SAP Solution Manager master and operations guide. This is why the detailed technical landscape documentation is not in focus of this standard. Chapter 5 shows helpful functions beyond the core solution documentation. Chapter 6, the appendix of this document, offers additional definitions, technical prerequisites and additional information to project preparation and implementation. After reading this standard, you will know how to fulfill the basic needs for an efficient lifecycle management and enterprise support, as well as the next steps to further benefit from SAP Solution Manager capabilities.
2011 SAP AG
Page 6 of 67
ALM processes span the six phases to ensure stable operation of the IT solution while enabling accelerated innovation. Optimizing these processes reduces costs, and ensures the highest quality of IT operation. Typically, multiple teams are involved in the ALM processes (see Figure 2.1). They belong to the key organizational areas Business Unit and IT. The names of the organizations differ from company to company, but their functions are equivalent. For example, a program management office communicates business requirements to the IT organization, decides on the financing of development and operations, and ensures that the requirements are implemented. On the technical side, the application management team is in direct contact with the business units. It is responsible for implementing the business requirements and providing support to end users. Business process operation covers the monitoring and support of the business applications, their integration, and the automation of jobs. And SAP technical operation is responsible for the general administration of systems and system diagnostics. Further specialization is possible within these organizations. For example, there may be separate experts for different applications within SAP technical operations in larger organizations.
2011 SAP AG
Page 7 of 67
Figure 2.1: Organizational model for application lifecycle management Two things are the key to optimizing the collaboration of the groups involved: a common infrastructure, and a clear definition of the collaboration processes, including the activities involved, responsibilities, and service levels. The infrastructure is provided by SAP Solution Manager as a collaboration platform. It provides role-based access to all functions required (provided either by SAP Solution Manager itself or by integrated tools), via work centers. It also provides all related information, centrally, so that all stakeholders involved have easy access to the information they require. Many customers have defined collaboration processes. SAP has leveraged the experience of these customers and of its own application lifecycle management experts to create best-practice descriptions of important ALM processes. These documents are published as E2E Solution Operations standards in SAP Service Marketplace at http://service.sap.com/supportstandards. Customers can refer to these standards when optimizing their own IT processes. With Run SAP, SAP provides a methodology for the implementation of the End-to-End Solution Operations standards. The road map for Run SAP guides through defining the scope of the operations to be implemented, preparing a detailed plan, doing the setup, and running SAP solutions. Moreover, it helps to find the right strategy and tools to implement ALM. The road map provides not only what needs to be implemented, but also contains information about how it needs to be implemented, in the form of implementation methodology documents and best-practices documents. Currently, SAP provides the following standards: Solution Documentation and Solution Documentation for Custom Development define the documentation and reporting required for the customer solution Incident Management describes the incident resolution process Remote Supportability contains five basic requirements that have to be met to optimize the supportability of customer solutions Root Cause Analysis defines how to perform root cause analysis, end-to-end, across support levels and technologies Exception Handling and Business Process and Interface Monitoring explains how to define a model and procedures to manage exceptions and error situations during
2011 SAP AG
Page 8 of 67
daily business operations, and how to monitor and supervise mission-critical business processes Job Scheduling Management explains how to manage the planning, scheduling and monitoring of background jobs Data Integrity and Transactional Consistency avoids data inconsistencies and safeguards data synchronization across applications, in distributed system landscapes Data Volume Management defines how to manage data growth Change Management enables efficient and punctual implementation of changes with minimal risks Test Management describes the test management methodology and approach for functional, scenario, integration and technical system tests of SAP-centric solutions. System Monitoring covers monitoring and reporting of the technical status of IT solutions System Administration describes how to administer SAP technology to run a customer solution efficiently Custom Code Management describes the basic concepts of custom code operation and optimization Security describes basic activities to setup, maintain and evolve security measures for the operation and organization of SAP solutions. Upgrade guides customers and technology partners through upgrade projects
Out of this list, this white paper describes the solution documentation standard.
2011 SAP AG
Page 9 of 67
2011 SAP AG
Page 10 of 67
The recommended documentation (project) language is English. To fulfill the SAP Enterprise Support requirements its sufficient to have an English speaking CCoE full time available. If needed, this CCoE contact can translate the information available in SAP Solution Manager. Regularly, though, the internal and external communication is more efficient if you choose English as default project language. To see the scope of services provided under the SAP Enterprise Support schedules refer to www.service.sap.com/enterprisesupport >> Scope Description for Direct SAP Customers. Solution documentation contains 2 types of documentation: the technical landscape documentation and the business process documentation. Dependent on the documentation content, the maintenance is done by different experts.
The data is displayed and maintained in the work centers SAP Solution Manager administration and the system landscape management.
2011 SAP AG
Page 11 of 67
Figure 3.2: Key elements of solution documentation Mission critical business processes are new or technically challenging business processes, e.g. with custom developments or non-SAP components needing high awareness or monitoring Documentation in SAP Solution Manager does not intend to model every process step variant and detail, but to have an understandable structure with information relevant for reuse of other teams and other application lifecycle capabilities Lets take a look at an example of the manufacturing industry: Material supply of the production
2011 SAP AG
Page 12 of 67
If this process is disrupted and material outages arise, the production of finished parts will be impossible. So, the company has to change production plans, causing higher total production cost In addition, customer orders will not be delivered in time, so that customer satisfaction decreases Therefore, the material supply process needs to be considered a critical core process, as in case of material outages the company loses a lot of money
o o o
Business Process: A business process is a set of logically related tasks performed to achieve a defined business outcome o o o A Business process is composed of several business process steps A Business process can run across several SAP components and possibly non-SAP software A Business process may occur in one or more Business Scenarios
Business Process Step: An elementary activity performed to accomplish a process o o o Is carried out by the user or by the system Runs in only one software component Is relevant to implementation and/or operation
2011 SAP AG
Page 13 of 67
Figure 3.2: Business process structure - example for 3-level process hierarchy If the maintenance of several transactions is necessary specify the standard transaction with the radio button Standard (see Figure 3.3).
Figure 3.3: Choose standard transaction in case of more than one transaction per process step
2011 SAP AG
Page 14 of 67
Figure 3.4: Solution documentation lifecycle Other processes and capabilities in SAP Solution Manager mainly use technical landscape documentation, e.g. change request management, system monitoring or root cause analysis. Integrating and reusing the technical and business process information with all SAP Solution Manager capabilities, solution documentation is the foundation for efficient application management.
The correct usage of implementation projects automatically leads to sufficient solution documentation in the operations and optimization phase. If you start with the documentation in the operations phase, you should re-document your core business processes in SAP Solution Manager as well. In relation to a complete implementation project, only a subset of information is needed then.
2011 SAP AG
Page 15 of 67
In brief, the technical landscape documentation provides: Central, reliable and up-to-date system landscape information for SAP and third-party tools Documentation of hosts, databases, systems, products, software components, system groups and logical components
In brief, the business process documentation provides: Central and clearly structured documentation of business processes, related systems and technical information Methods and tools like solution documentation assistant to keep this documentation efficiently up-to date Business, landscape and technical view enables internal business and IT alignment Central access to documentation makes internal projects and collaboration with SAP efficient
Solution documentation functions as basis for the whole application management lifecycle. It ensures that customers achieve transparency of their IT solution landscape and business processes. Moreover, it fully exploits the potential of SAP Enterprise Support. More detailed information on SAP solution documentation can be found under https://service.sap.com/alm.
2011 SAP AG
Page 16 of 67
Figure 4.1: Navigation in the guided procedure for the SAP Solution Manager basic configuration, transaction SOLMAN_SETUP To use the basic scenarios of SAP Solution Manager, the following configuration scenarios must be performed successfully: In the system preparation, you make settings which are a prerequisite for the configuration of SAP Solution Manager. In the basic configuration, you perform the necessary configuration which is needed to use basic scenarios in SAP Solution Manager, for example, connecting to SAP, performing a root cause analysis, using the SAP EarlyWatch Alert, or downloading patches and upgrades.
2011 SAP AG
Page 17 of 67
In the Managed System Configuration, you connect managed systems to SAP Solution Manager. You have to perform this scenario for each managed system separately.
The details regarding technical landscape documentation are described in the SAP Solution Manager Master and Operations Guides.
2011 SAP AG
Page 18 of 67
Figure 4.2: Decision Tree: How to come to a central and reliable business process structure with related documents in SAP Solution Manager
In case that you are in operations mode already, it is more efficient to use the solution documentation assistant to verify this draft with the usage data of your productive system. Based on usage data of technical objects, the solution documentation assistant allows the analysis if, and how often, business processes and business process steps are used, and which related technical objects need to be documented. This is valid for SAP and non-SAP transactions and programs as well. The solution documentation assistant use cases and its detailed functional range will be described later in this document. For all use cases is valid that the analysis data should be discussed with a business process expert and then adjusted in the business blueprint. If new processes, process steps are assigned, upload or link the appropriate documentation on the project documentation tab.
2011 SAP AG
Page 19 of 67
If you are well aware of your business processes and the linked technical objects, and have your own company specific nomenclature differing from SAPs wording in the implementation content, you can maintain the processes manually and directly in the blueprint structure (see figure 4.3). In case of few and well known processes and process steps, this is the fastest method to document the initial process structure.
Figure 4.3: Manual re-documentation or maintenance of business processes Valid for all use cases is that, once maintained, business processes can be automatically verified with the help of the solution documentation assistant (see chapter 4.6).
2011 SAP AG
Page 20 of 67
Figure 4.4: Working with prefixes allows reducing the number of business process structure levels
2011 SAP AG
Page 21 of 67
Create a project & system landscape in SAP Solution Manager 1. Select content from Business Process Repository or manually maintain process structure in the newly created project. Assign transactions to the process structure. 2. Transfer the project to ARIS Business Architect for SAP NW 3. Extend the basic business process via detailed modeling in ARIS Business Architect. ARIS scripts allow the re transfer of the detailed ARIS modeling information to the basic 3-level IT view to be exchanged with SAP Solution Manager. 4. Synchronize the adjusted process structure inclusive transactions, documents and SAP system landscape information back with SAP Solution Manager
Figure 4.5: Exchange business process information with the modeling tool ARIS Business Architect for SAP Note: The integration is part of the SAP Enterprise Modeling Applications by IDS offering at no additional costs. It is delivered as an ABAP import within the SAP Enterprise Modeling Applications by IDS offering.
2011 SAP AG
Page 22 of 67
Identification of related top issues and areas of concern o eliminate existing and potential issues for solution
Analysis and description of o o o the core business processes (see figure 4.6) and solution landscape the system landscape and related interfaces the issues and recommendations to be applied
Detailed action and service plans to address identified issues and recommendations
2011 SAP AG
Page 23 of 67
Figure 4.6: Core business processes defined in SAP Solution Management Assessment service SAP Solution Management Assessment has been delivered more than 100 times per year for 10 years.
2011 SAP AG
Page 24 of 67
benefit of the SAP Enterprise Support offerings, your custom development solution documentation has to contain (see figure 4.7): A business process step with a meaningful name A short description of the development on project documentation or development tab. The related development objects, e.g. programs or transactions in the customer name space When released the finalized programs and transactions have to be maintained on the transactions tab. Only then it can be reused for other SAP Solution Manager capabilities like Solution Documentation Assistant and Business Process Change Analyzer.
Customer developments can be programs that are implemented in SAP applications, independent applications that are operated in addition to an SAP application, and that are connected to it via interfaces, or changes to existing standard applications (modifications).
Figure 4.7: Key elements of custom code documentation The Standard Solution Documentation for Custom Development describes the requirements and gives step by step guidance how to do solution documentation for custom developments.
2011 SAP AG
Page 25 of 67
Figure 4.8: Interface documentation of scenarios, attributes and where used check Define a meaningful scenario name and add the list of single interfaces to the scenarios. This is done on the Structure tab as well. Enter the sending and receiving logical component and via application help the interface technology and type. Using the attributes button, you have the advantage to document interface details in a guided way. Using this button, you are asked for the central information typical for interface documentation. As you are linked to the managed system, you can choose values directly out of the data from the managed system (see figure 4.9). So it is ensured that the spelling is correct and the content really available. Alternatively or in addition, you can add already existing and valid documentation to the project documentation tab. Configuration data of interfaces you maintain in the business process structure on the configuration tab in the predecessor and successor process step of the interface.
2011 SAP AG
Page 26 of 67
Figure 4.9: Attributes maintenance, application help leading to the managed system If you have done the interface documentation this way, a user with information needs can check directly via the graphics or via the W here used button, in which process an interfaces is used (see figure 4.7). In the standard solution documentation for Custom Development you find a more detailed description of how to maintain interface documentation. In the SAP Service Marketplace alias ALM, under Processes, Solution Documentation, Capabilities, Business Blueprint and Solution Directory, you find demos showing how to maintain interfaces and how to transfer them into a solution.
4.4 Reporting
While the project duration, SAP offers a collection of useful reports in one transaction allowing a fast ad-hoc reporting. The reporting can be accessed directly via transaction SOLAR_EVAL, or from the Implementation/Upgrade work center navigation area Reports (see figure 4.10).
2011 SAP AG
Page 27 of 67
Figure 4.10: Reporting via the Implementation/Upgrade work center Moreover, the project phase specific transactions (e.g. SOLAR01 for the Business Blueprint) allow to jump into the reporting transaction (Environment > Project Analysis). All assignments that are done in the business blueprint or in the realization phase of a project can be evaluated. The project analysis and analysis results display options are very flexible. You can use selection criteria to restrict the scope of the analysis. You can also specify the presentation of the analysis results. You can create standard analyses and save them as selection variants. You can call the displayed elements of the project structure or IMG activities directly from the output.
2011 SAP AG
Page 28 of 67
case of bigger changes, the solution content is the perfect backbone for a new upgrade project (see figure 4.11).
Figure 4.11: Application lifecycle management is based on projects and solutions After the go-live of a project and the copy of the project information to one or several solutions, the project is locked for changes, and the solution contains the up-to-date documentation of all core business processes and the supporting productive system landscape information. So, scenarios, processes, process steps, master data, organizational unit structures, and all linked documents, configurations, transactions, test cases and learning maps are available for solution operations (see figure 4.12) . When you are copying a project, interfaces are not handed over automatically. To transfer an interface to a solution, you have to select it via the selection help at the interface structure tab of a solution. Then mark and assign the interface in the graphics tab.
2011 SAP AG
Page 29 of 67
Figure 4.12: Projects and solutions have nearly the same structure and content Solutions allow the controlled maintenance of business processes and dedicated information via maintenance projects and check-out/check-in functionality. So, the benefits of a solution are up-to-date, central solution documentation with a reliable solution documentation to be used in the complete operations phase. In addition, the information available with the solutions are basis for many other SAP Solution Manager capabilities, like business process and interface monitoring, upgrade projects, knowledge transfer and issue management. Solutions are accessed via the Solution Manager administration work center or the solution directory (transaction SOLMAN_DIRECTORY). They contain information, data, and documentation similarly structured to projects. The highlighted areas in figure 4.13 show the main differences from projects. 1. 2. The list of maintained solutions is shown in the navigation tree Productive systems must not be changed without controlled access; so the Configuration tab is for display only.
3. The controlled access and change is provided by the check-in/check-out mechanism, which can be extended to a full change request management workflow. 4. The last entry in the navigation structure is folders listing system and server information supporting the business scenarios and processes above
2011 SAP AG
Page 30 of 67
Figure 4.13: Content differences of projects and solutions To transfer documents from projects, the business process repository or other solutions, into your current solution, you can copy or reference documents or transfer documents of selected document types only, e.g., specifications, requirement or customer-defined document types.
2011 SAP AG
Page 31 of 67
Usually small and midsize customers do not need more than one solution (see figure 4.14).
Figure 4.14: Solution design of a small to midsize company As big companies have several org. units and core business processes implemented or maintained in parallel, solutions can be tailored due to the specific needs. Creating more than one solution, several factors should be taken into account: Organizational units of a company or a corporate group, also their structure, required technical availability, etc. (see figure 4.15).
Figure 4.15: Solution design of a global oil company Another important factor having influence on the number of projects and solutions is the organizational view relevant within a corporation. Individual customer organizations split responsibilities related to systems and processes. Thus, solutions might be defined according to organizational structures, such as company structures, business units, support organizations, or regional organizations.
2011 SAP AG
Page 32 of 67
As a rule, such units are organizationally independent, including the customer IT departments and possibly also the support centers. In such cases it makes sense to create different solutions. The end-to-end business processes across all involved systems/logical components (also third-party) One of the most important criteria for a solution unit is the integrity of business processes. From a logical point of view, it is necessary to have all of the business process steps that are related to the same core business process in one solution. This is especially important if you plan to set up business process monitoring, in order to enable the monitoring of a complete business process within one solution. It is also required for the delivery of SAP Services that analyze business processes (Business Process Performance Optimization, Solution Management Assessment, Technical Integration Check, and so on). One service can only be assigned to one solution, so all (Please also refer to the Best Practice Document SAP Solution Manager Solution Lifecycle (www.service.sap.com/solutionmanager -> Media Library -> Technical Papers) necessary business processes and business process steps must be contained in that solution for successful service delivery. Additional reasons to create more than one solution might be: o o o o o Data sensitivity, allow access only for specific roles, user groups or org. units Parallel maintenance cycles System responsibilities Monitoring SAP and non-SAP systems is separated Performance in case of very big projects with thousands of process structures and objects
2011 SAP AG
Page 33 of 67
Option 2: Extended check-in/check-out with change request management. The check-in/check-out process can be combined with the complete change request management functionality (see standard change management) Option 3: Maintain directly in solution directory. Due to the lack of control and a decreasing reliability and accuracy of the solution documentation, this option is not recommended.
Option 1: Check-in/Check-out workflow Changes to the sub-structures "Organizational Units", "Master Data" and "Business Scenarios" are made in the maintenance project assigned to the solution on the Solution Settings tab in the Solution Directory (see figure 4.16).
Figure 4.16: Assign or create a maintenance project for a solution, and activate the history To change an object, a request is sent to the solution administrator who has approval authority If approved, the object can be checked out to the assigned maintenance project
2011 SAP AG
Page 34 of 67
Once all changes have been made, the checked out sub-structure is set to Ready for check-in in the maintenance project, and can be checked back in to the solution directory (see figure 4.17) This procedure works without a formal change request workflow (the check box Enable Change Request Management has been left unchecked).
Figure 4.17: Solution maintenance workflow Via the history push button, projects and solutions provide information of changed business process structures, documents, transactions, issues, end user roles and other administrative data. Via the history you can answer questions like: W ho did, when, which kind of changes? (see figure 4.18)
2011 SAP AG
Page 35 of 67
Figure 4.18: The history shows who did change what The transactions Business Blueprint and Configuration provide a context check, investigating if the maintained technical objects on transaction tab are really available in the managed system. Run this check before a go-live and the do a solution documentation assistant analysis to ensure data reliability. To perform the context check, choose your project, go to the menu entry Update Component System Check and start a report to identify misspelled or outdated technical objects (see figure 4.19). Done that, you can remove not existing objects out of your solution documentation, or add the missing objects to the managed system.
Figure 4.19: The Context check allows the identification of obsolete solution documentation
2011 SAP AG
Page 36 of 67
4.6 Verify the process structure and related objects with solution documentation assistant
Customers need clarity and transparency about their current situation. To find the right starting point, it is important to identify which data exists, and which processes are already documented. Information about planned and scheduled activities also helps to identify the use cases for solution documentation assistant in these plans. Typical customer pain points which describe where solution documentation assistant can support customers, partners and consultants are: Is my external maintained business content still up to date? How can I use SAPs implementation content to validate my business content in SAP Solution Manager? How can I use solution documentation assistant to start maintaining my business content in SAP Solution Manager? Is my maintained project content still valid? Is my solution content still valid?
Solution documentation assistant (SoDocA) verifies and rates customers business process documentation. Data basis is the usage frequency of technical objects related to the business process structure. The usage frequency gives transparency about potentially obsolete objects, clarity about mission-critical objects, and is an excellent starting point for initial documentation as well. As the prerequisite for the usage of the solution documentation assistant is to have system data available, most of the use cases are related to the operations phase. Solution documentation done with the solution documentation assistant has the big advantage that it is based on the real usage of your system and not on theoretical models and concepts.
SQL statement analysis, the involvement of table entries, enables a detailed live system analysis from a business perspective. This: facilitates business improvements causes standardization through comparison of business processes at different locations
Solution documentation assistant is a young functionality which will be further developed with the next SAP Solution Manager releases. Its focus remains on the verification of the business
2011 SAP AG
Page 37 of 67
process structure and related technical objects. It has an interface to up and download configuration content (rules), enabling SAP consulting or partners to use templates for a fast initial documentation or analysis of business processes
If no business process documentation is available, you firstly should check the SAP standard documentation, the predefined SAP implementation content (BPR) (see figure 4.21). Create a new implementation project. Use the BPR as template, selecting the scenario(s) likely reflecting your core business process(es). Verify the scenario(s) with the help of solution documentation assistant. You will quickly identify which of the standard processes are used. Update the original project or create a new one. In a second run, remove the not used structures and enrich the business process structure with your custom developed objects and non standard process steps, and define more specific rules. With this method you quickly come to a reliable documentation of your core business processes based on real usage data. Extend the documentation with critical processes or selected scenarios using BPR, and verify the additional structures as shown above. Automatically and regularly verify the project to keep the documentation reliable and up-to-date. So, the key advantages of this method are to get a starting point, enable prioritization of business processes by system usage, and the ability to verify the documentation progress.
2011 SAP AG
Page 38 of 67
Figure 4.21: Discover Alternatively, if you do not want to use the SAP standard, you can use the usage information of the solution documentation assistant to manually create the initial business process structure, and document the related objects on the transactions tab. The verify use case works very similar, the only difference being that you already have a project or solution as starting point for verification available. Going into the details of a solution documentation assistant analysis, the rating of a node includes both sub nodes and the identifying check items directly assigned to the node level (see figure 4.22). The analysis results of the check items and check steps that are assigned to the check items are displayed in the screens next to the tree structure.
2011 SAP AG
Page 39 of 67
Figure 4.22: Business process verification Results are displayed with a rating. Depending on the results, the structure nodes have the following rating possibilities: Green: The node is active Yellow: The node may be active. The result summarizes different status: o The results for a structure node take into account the analysis structure hierarchy, as well as the assigned check items. This way, the result of a business scenario summarizes, for example, the results of all assigned business processes. This can cause the status 'possibly active' if, for example, a business process has both active and inactive process steps o The results of the analysis for all time periods are shown by default. A node can have the status 'possibly active' if, for example, it is only active during a specific time period Red: The node is not active Grey: The node has not been rated, e.g. the node had no flag and was not analyzed
You can use the results of an analysis to update an existing Solution Manager object or create a new one. If you have created an analysis project based on a Solution Manager project, you can update the Solution Manager source project with the results of the analysis. Creating or updating the SAP Solution Manager project, you can adjust the effect of the default rating. For each type of rating, for example Active, Inactive or Probably active, you can choose one of the following rules in the Update Action column (see figure 4.23): Set in Scope Set out of Scope Do Not Change
2011 SAP AG
Page 40 of 67
Figure 4.23: When creating/updating a solution manager project, define when the scoping flag is set and when left blank. In the project, the checkbox in front of a business process is then accordingly marked as In Scope or Out of Scope (see figure 4.24).
2011 SAP AG
Page 41 of 67
In the next run of your analysis you can then choose to use only those structure items and technical objects which are in scope. Alternatively you can take the not sufficiently used structures and objects into account as well, but keep an eye on them. After some time, when you are sure that they are truly obsolete, delete them from your solution analysis or exclude them from your further analysis.
The rule database lets you search for check steps. The results table displays all check steps in the rule database that meet the search criteria. You can search for specific check steps with detailed criteria. For each check step, detailed information is provided, such as: Name of the check step. By default this is made up of the name and description of the referenced object in a transaction, for example, SE16 Data Browser. Type of check step, for example, transaction User who last changed the check step Time of last change
In some cases, the automatically defined check steps based on transactions like the common VA01 are not specific enough to get an insight of the usage of a business process or business process variant. In this case, the check steps of a process structure can further be enhanced with additional rules, including thresholds, e.g. with additional check steps reading database table entries. You can create SQL check steps that check the following cases: Whether a specified database table is present Whether a specified field of a database table is present Whether specified values occur in fields of a database table How often certain values occur in fields of a database table
Figure 4.25 shows the result of such an enhanced, self defined process step. Here, two order types, standard order and promotion order, have to be checked and compared. The additional rule for: the standard order contained a check on table VBAK, column AUART, Value OR the promotion order contained a check on table VBAK, column AUART, Value AA
2011 SAP AG
Page 42 of 67
The result was that, during the time period of the last three months, the standard order had 680 table entries, the promotion order 0 table entries. This allows several conclusions to be checked with the business process champion or expert, e.g.: the promotion order business process step is potentially obsolete the process to use the promotion order is not known by the end users and there should be an additional training the promotion order process step is valid, but not executed in the selected time period (this could as well be the case for seldom used BI processes)
Figure 4.25: Business process variants As summary you can say, that the analysis project independent rule database allows the reuse, display and management of all rules. This makes sense especially for self-defined rules requiring some business know-how, e.g. checks of specific table entries.
2011 SAP AG
Page 43 of 67
Figure 4.26: Housekeeping display of not used objects Depending on the type of check steps used, the analysis results are summarized under different aspects, for example: All transactions and reports SAP transactions and reports Customer-specific transactions and reports
The following result types are displayed for each of the three named groups (for further details refer to the online documentation on the SAP Service Marketplace): Analyzed Not analyzed because, for example, there is no data for the client you specified when creating the analysis Not analyzed in other clients Used. The objects are used in the analysis period and in the systems specified for the analysis Not used (only affects customer-specific transactions and reports)- if you have selected the Get All Customer Objects option when you created the analysis
Analyzed results can be reused as check-steps. For this, the listed results can be added into the Rule Database and accessed via the Analysis Project view Selecting the Get All Customer Objects option creating the analysis, solution documentation assistant displays you a quick overview of the not used objects for a chosen time frame. This is a good starting point to identify potentially obsolete coding, and for housekeeping activities. The expert tool analyzing and managing custom code professionally remains the custom development management cockpit (CDMC). How to manage custom code is describes in the standard Custom Code Management
2011 SAP AG
Page 44 of 67
Figure 4.27: Governance If some business processes have not the expected usage frequency, you identify the root cause of the problem and e.g. intensify the local roll-out, or adjust the business process and its documentation. Technically, the maintenance of projects and solution works in the following way (see figure 4.28): After finishing your template/implementation project, you copy the data into one or several solutions. The solution is the data source for the solution documentation assistant analysis project. Planning to create a new project out of an analysis, but to keep the project documentation and configuration data, copy the source project and update the copy with the analysis results. On the other hand, this copy leads to a break of information in the application lifecycle between the source project and the copy. So, you are only able to work with the compare and adjust functionality for template and source project, and separately for the project copy and derived solution. In the analysis, the usage data is derived from SAP Solution Manager (EWA) and Satellite Systems (RFC). With the analysis results, you can update the source project or create a new
2011 SAP AG
Page 45 of 67
project. For a controlled update of the solution via check-in/check-out functionality, create a new, or update the existing maintenance project related to the solution.
Figure 4.28: Solution documentation assistant data flow before and after project analysis best practice
2011 SAP AG
Page 46 of 67
Figure 4.29: Use solution documentation assistant to prioritize processes and objects to be tested, as well as to check test execution
Figure 4.30: Show period details of a check step to display the usage frequency development of a specific technical object
2011 SAP AG
Page 47 of 67
assistant
data
sources
and
The solution documentation assistant manages information about projects and productive solutions. If you create an analysis project choosing the data source, a specific project or solution, the business process structure is automatically transferred (see figure 4.31).
Figure 4.31: Automated transfer of business process structure from chosen project of solution Out of the technical objects on the transaction tab, check items and check steps are automatically created as well. The analysis project in Figure 4.32 shows the analysis structure and the check rules (check items including check steps) assigned to the analysis structure nodes. The solution documentation assistant offers you a view showing the structure and details of an individual analysis project. The screen is divided into two related parts. On the left-hand side, analysis structure mirrors the structure to be analyzed and matches the structure source, which can be implementation projects, solutions, or an uploaded partner project structure. The right-hand side contains check items, check steps and threshold values, which are listed in a hierarchical order and are related to the selected structure node (see figure 4.31).
2011 SAP AG
Page 48 of 67
Figure 4.32: Solution documentation assistant analysis project containing process structure linked to check items and check steps The process structure mirrors the business processes to be analyzed. The check rules rate the analysis structure nodes in the analysis. Check rules are the check items and check steps that belong to a structure node, for example, a business process. The check rules are displayed in two tables: Check items are the header for one or a group of checks steps. Check items are the link between structure items and check steps. A check item stands for one variant to analyze the linked process structure. It is possible to assign several check items to a structure item. Check steps contain the technical objects to be analyzed and the threshold value to identify the usage rate as true or false.
The relation of business structure and rules with usage results allows rating the business structure later on. Having the process structure and rules defined, the customer system landscape environment provides the usage data via the SAP EarlyWatch alert infrastructure (see figure 4.33). The managed systems must have release 4.6C or higher.
2011 SAP AG
Page 49 of 67
Figure 4.33: Data sources of usage data The data transfer for the workload statistic data is managed by the SAP EarlyWatch Alert service session, which is already part of our SAP support engagement. The SAP software component ST-PI has been enhanced to collect the workload statistics data. This enhanced service has to be activated via the SAP Solution Manager customizing IMG. After activation, the workload statistics data is transferred via the SAP EarlyWatch Alert. To read the EWA data, the SAP Solution Manager standard RFC connection SM_XXXCLNTXXX_READ is used. Customer managed systems are additionally connected with the customers SAP Solution Manager via another remote function call connection (RFC). To get access retrieving real time data, e.g. SQL and BAdI data, the SAP Solution Manager standard RFC connection SM_SIDCLNTXXX_TMW is used.
2011 SAP AG
Page 50 of 67
Figure 5.1: Project documentation tab for maintenance of project specific documentation Documents can be assigned to specific process structure elements, such as scenario, process or process step (see figure 5.1). You can develop your own document templates, or use templates delivered by SAP, for example, business process procedures or configuration guides. Done that, you can assign document types to project types (implementation, template, upgrade and maintenance) in order to make it available for blueprint, configuration and other project phases. The definition of document types can be done centrally in SAP Solution Manager using transaction SOLAR_PROJECT_ADMIN. After the document type is created, the file can be created using the editor, or uploaded from a local file. The document settings are used to steer the availability of the document types: Global document: Document types indicated as "global" do not need to be explicitly assigned to a project. Non-global document types have to be assigned to those projects in which they shall be available. A document type can be assigned to more than one project.
2011 SAP AG
Page 51 of 67
Several documents allowed: allows assigning several documents of the same document type to one structure node. File extension: specify the extension of the document. This is needed if the document template will be created based on the editor. Blueprint relevant: if the document based on this template will be treated blueprint relevant or not.
The status schema allows to restrict the number of status values, and to present them in a specific order. These status values are then assigned to documents, allowing using the document template in this specific order. Additionally, an initial, locked and final status can be defined. Further more, a digital signature can be assigned at a status value level. This digital steers if a specific status requires a sign or not. Digital signature based authorizations prevents uncontrolled document changes. The change history and versioning of documents allows tracking of changes. A full-text search based on TREX (separate installation) is supported for all uploaded documents, allowing an efficient work with your managed documents
Figure 5.2: Configuration documentation on tab Configuration Besides using the SAP pre-defined implementation content like IMG Objects and BC Sets, you can as well develop and document customer-specific developments, so getting transparency through central storage of all documented customer-specific developments. The central and predefined access to your managed systems allows time-efficient customizing without reiterative logon. As well the processing status can be tracked, and the responsible processors visualized. SAP Standard Solution Documentation Version: 2.0
2011 SAP AG
Page 52 of 67
The access to the managed system is enabled via trusted trusting RFC connection and logical components. The trusted trusting RFC technique allows a fast, generic logon to the managed system. In the managed system the user has not more authorizations, but only those previously assigned to the user. Customizing settings can be collected by processes into Business Configuration Sets (BC Sets). BC Sets make customizing more transparent by documenting and analyzing the customizing settings. They can also be used for a group rollout, where the customizing settings are bundled by the group headquarters, and passed on in a structured way to its subsidiaries. Advantages of using BC Sets: Efficient group rollout Industry sector systems are easier to create and maintain Customizing can be performed at a business level Change Management is quicker and safer Upgrade is simpler
After creating new BC Sets, you have to assign them to the process structure element. Check the content of the assigned BC Sets. Delete the assignments of BC Sets that are no longer required from the project in the application systems. Activate one or more assigned BC Sets. The status of activated BC Sets is shown in the configuration tab.
Manual test cases can be linked to transaction or program, accelerating the test case creation and execution. But SAP Solution Manager offers much more than only an assignment of test cases and linking of technical objects. For instance, you can generate test plans automatically by using the business process hierarchy, so enabling the continuity of end-to-end business processes via central test management. The creation of test packages, reporting, or risk based testing as well benefits of, or interacts with, the process structure and its related information. To get an overview about the test management options and details, refer to www.service.sap.com/alm >> Processes >> Test Management. The integration of the SAP Solution Manager test management functionality in SAP HP Quality Center by HP has been described in the SAP Professional Journal Vol.10 (2008), Issue 3 (May/June) in detail.
2011 SAP AG
Page 53 of 67
Note: It is recommended to assign the test information directly to the lowest level of the process design, the process step.
5.2 Which expert functionalities does the business process documentation offer?
Having your basic solution documentation in place, the next question is how to do a more detailed modeling, and reuse this information in other application lifecycle phases. Up to now, the focus of SAP Solution Manager was not to offer detailed modeling capabilities. Nevertheless, it offers several possibilities addressing different blueprint creation and modeling needs: Templates o Reuse of complex, predefined information to support global roll-out processes across geographical distances Short Cuts o Links to reuse process structure elements Customer Attributes o Name-value combination to specify and differentiate process structure elements Key Words o Name to specify and differentiate process structure elements Graphics o Visualize and document simple business process step variants graphically
In general it has to be said that the modeling of business processes is a very customer specific task. It is dependent on the customers organization, ALM phase, information to be rd added, reuse needs, and connected 3 party or partner tools. So, it is not possible to offer a general best practice, but in the following, you will get a brief overview of the possibilities working with the business structure, their benefit, and limitations.
2011 SAP AG
Page 54 of 67
Figure 5.3: Template Management Supporting Global Rollout process flow Main template management features are: Template definition, implementation and optimization of whole projects and roadmaps, or linked information, like roles, configuration information and document types Bundling of business processes and standardization Link to process-specific developments, configuration, and test data
This predefinition of standards leads to transparency, allows accelerated rollout to other company locations and to cost efficient re-use of existing business process and configuration information (see figure 5.4).
2011 SAP AG
Page 55 of 67
Figure 5.4: Reuse of configuration templates in configuration The following modeling methods address not so much the standardization of whole projects, but rather the time-efficient modeling and modeling of business process variants.
Figure 5.5: Use short cuts to reuse business process structures and linked information within or across projects and solutions SAP Standard Solution Documentation Version: 2.0
2011 SAP AG
Page 56 of 67
The usage of short cuts reduces the manual effort during documentation of a large number of processes. As you can make changes in a central place, changing structures within a dynamic project, and maintenance of big business structures, can be done more time efficient. As figure 4.9 shows, short cuts can be a method to model business process variants as well. As each process structure in each project or solution has a unique identification number, (GUID) adjustments in case of transfer to other projects or solutions are necessary. That means that, after the copy of a project or solution, the short cut needs to be adjusted so that they point to the correct target structure node in the new project or solution, and not to the original structure node. Note: With release of SAP Solution Manager 7.0, this technology cannot be recommended in case the process documentation is re-used for the Business Process Change Analyzer (BPCA). Idea behind is that the related technical bills of material (TBOMs) currently cannot be assigned, currently.
Figure 5.6: Use attributes to make specific project information visible for specific project team members or company organizations The customer attributes allow differentiation of business processes, and document business process variants. The customer can choose which attributes he wants to define, as well as which and how many values they should have. Once defined, the attributes and their values
2011 SAP AG
Page 57 of 67
are applicable to all (!) projects. The configuration is centrally done via the SAP Solution Manager Implementation Guide (IMG).
Figure 5.7: Use keywords to specify and differentiate process structure elements One of the benefits of using keywords is the possibility to differentiate business processes, e.g. High priority processes, and the good ad-hoc reporting options using project reporting (transaction SOLAR_EVAL) or filters. Note: Structure element associations with keywords currently cannot be transferred to SAP Solution Manager solutions.
5.2.5 Graphics
If you want to visualize and document simple business process step variants graphically, business blueprint provides the option to use graphic tab. Here you can model process steps and simple variants visualizing and documenting the business process variants along the process flow sequence (see figure 5.8). You can only model on process level. As well, the modeling is limited to less complex variations as it is not possible to model complex
2011 SAP AG
Page 58 of 67
structures, e.g. with if and or operators. The graphics can be exported in MS power point format.
The graphic in the graphic tab at process level visually addresses the following questions:
Which process steps does the process contain? In which logical components do the process steps run? What dependencies exist between process steps (predecessor -successor relationships)?
2011 SAP AG
Page 59 of 67
6 Appendix
To make sure that the different groups establish a common understanding, it is necessary to define the term solution first. Furthermore, definitions of the elements of a solution are required.
2011 SAP AG
Page 60 of 67
provide information that is required to perform the process step, but is not available in the leading component, e.g. availability check in a warehouse management system during sales order processing in a CRM system. In such cases, the function invoked needs to be represented as an additional business process step.
6.2 Solution
The solution is the entirety of all system components and processes that represent a central business function or a business area in an information system. A company will have a number of solutions in parallel in order to reflect the different business areas and central functions in its information systems. Each solution consists of a number of components that are either process components or system components. As different entities of the company may use the same business process or system components of a solution, a component may in general be part of different solutions. The solution directory in SAP Solution Manager integrates the documentation of the process components and the system components. Solutions in SAP Solution Manager group systems of a customer solution according to certain criteria, for example all systems used in a specific business process or administered by an individual team in the SAP technical operations department. Solutions in SAP Solution Manager are used to provide filtered views on the end-to-end customer solution. As such, the solution directory is relevant for all steps of the documentation methodology. For business processes that have not been documented in a project yet, the documentation can be done directly in the solution directory, as well.
2011 SAP AG
Page 61 of 67
systems run on product version SAP CRM 5.0, whereas the productive system is not yet upgraded and runs on SAP CRM 4.0. Client: A self-contained unit in an SAP system with separate master records and its own set of tables. Instance: Instances are the smallest elements for designing system landscapes. They group technically dependent software component versions, which have to be installed and operated on a single logical system/server. Software component: The software component is the smallest unit that can be delivered, maintained, and deployed. It provides the technical view on the software. Each software component is installed and patched as a whole. The software component version indicates the release of a software component. A product version consists of multiple software component versions. One software component can be used in several products. Logical component: A logical component is a system-related entity that describes an instance of an SAP solution, e.g. SAP ERP. It specifies on which SAP or non-SAP product a dedicated business process runs (or, more precisely, a process step). Logical components contain all currently needed system roles, like development, test, quality, production or demo system. Those system roles can be centrally maintained in SAP Solution Manager, e.g. when a test system has been replaced by another. Wherever the system information is used, the new status will be automatically updated. Typically, business and IT together determine which logical components are required by a project. This can be defined for SAP solutions, non-SAP, or third-party products. This helps you to describe your entire software solution in SAP Solution Manager, regardless of whether SAP or non-SAP software is implemented. In the context of business process modeling in SAP Solution Manager, a business process step always runs on one logical component, which is very often reflected by a system/client combination.
2011 SAP AG
Page 62 of 67
Keeping total cost of ownership low, and the performance of your SAP solution high, is a tremendous value to your business a value delivered by the SAP EarlyWatch Alert. Knowing the status of each SAP component in your solution allows you to: greatly minimize the risk of downtime react to issues, such as bottlenecks, before they become critical know what is affecting the performance and stability of your solution
The underlying concept of the SAP EarlyWatch Alert is to ensure smooth operation of individual SAP components by taking action proactively, before severe technical problems occur. This monitoring tool is based on experience with thousands of installations giving you a tool to save time, reduce costs and keep your SAP solution running smoothly. ST-PI: The add-on Solution Tools Plug-In (ST-PI) provides basis and trace tools required for service delivery and system monitoring. The solution tool plug-in contains the latest version of: Function modules for data collection Transaction SDCCN (Service Data Control Center) Application Specific Upgrade: ASU-Toolbox Custom Development Management Cockpit (CDMC)
2011 SAP AG
Page 63 of 67
SAP_SMWORK_BASIC (provides all the necessary authorizations for the work centers themselves, such as authorization for POWL (table control) and navigation. It needs to be fully maintained, including profile generation and user comparison) SAP_SMWOORK_SDA (provides the navigation information needed to work with that work center)
Solution documentation assistant roles: SAP_SDA_DIS (provides display authorizations) SAP_SDA_ALL (provides full authorizations)
Solution documentation assistant uses the existing SAP Solution Manager infrastructure, like system connections and technical statistical data coming with the EarlyWatch Alert, so that nearly no additional configuration is necessary. Activation and related user authorization have to be set-up via the implementation guide (IMG) and PFCG user roles. Minimum release and support package level is SAP Solution Manager release 7.0, SP 16. but as the work center has been enhanced significantly, SP 18 is recommended. The managed systems must have release 4.6C or higher and at least the ST-PI release 2008_1_* SP00 installed. To have usage data available, the SAP EarlyWatch Alert must deliver data a minimum of one month before the first analysis run starts. The solution documentation assistant takes into account data of a full month, meaning that the latest month available for a current analysis is the preceding month.
2011 SAP AG
Page 64 of 67
Verify (Solution Documentation Assistant Work Center, transaction SOLAR01 and SOLAR02)
project before you can access the managed systems in subsequent project phases. Then you can centrally manage all the landscapes you require for your project using the SAP Solution Manager.
Define the project language o When you choose a project language, all language-dependent information for this language (project documentation and status information) is made available to project members. This is independent of the logon language of the project member o The project structure is created, and all content is stored in the selected project language as well
2011 SAP AG
Page 65 of 67
After the project language has been selected and saved, it cannot be changed.
The main optional tasks are: Determine general data, e.g. project responsible, plan data, milestones Assign project team members and organizational units Define project standards (status values, documentation types, keywords, status schemes for document types) Activate access concept per structure node Activate quality gates
The effort of optional tasks depends very much on the purpose you want to use your project for. In a template project you may focus on the definition of document templates, but in an implementation project you may focus on the definition of your project team members.
2011 SAP AG
Page 66 of 67
Copyright 2011 SAP AG. All Rights Reserved All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifi cations may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (SAP Group) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. This document is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this document or to develop or release any functionality mentioned in this document. This document and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice.
2011 SAP AG
Page 67 of 67