Document Management In SAP Solution Manager Application Lifecycle Management

Transcription

1 Document Management In SAP Solution Manager Application Lifecycle Management

2 TABLE OF CONTENTS 1.0 Motivation Method and Prerequisites Document storage in SAP Solution Manager Document types Status schema and digital signature Customer attributes for documents Automatic generation of a Blueprint, Configuration Guide and Test Report Documentation process and responsibilities Usages One project as single source of truth Document management during maintenance Document management during major release Summary Solution as single source of truth Document management during maintenance Document management during major release Summary Template as single source of truth Document management during maintenance Document management during major release Changing documents stored on the General Documentation tab Summary Authorizations in Document Management Restrictions between projects Restrictions within a project structure Restrictions within the document management (different KW Folders) Standard authorization roles Project administration (SOLAR_PROJECT_ADMIN) Business Blueprint (SOLAR01) Configuration (SOLAR02) Solution Directory (SOLMAN_DIRECTORY) Glossary Linked Documents... 22

3 1.0 Motivation The goal of Solution Documentation in SAP Solution Manager is to have central documentation for ITsupported business processes and technical information about SAP and non-sap solutions for transparency and efficient collaboration. Business process documentation represented in the Application Lifecycle Management (ALM) process Solution Documentation is embedded as an integral part of the lifecycle management concept. It can be viewed as the foundation for ALM and, like a foundation or groundwork of a house, its value consists in building a strong and reliable base for the house built on top of it. For ALM, this means having strong, reliable and up-to-date business process documentation in SAP Solution Manager will allow you to benefit from other ALM capabilities built on top of it. These benefits are measurable and, in the end, will help you save time and money. The basis of the business process documentation is the business process structure. It gives order to the assigned business process documentation. The design aspects of the business process structure is not part of this document, but of the document ALM Architecture Design in SAP Solution Manager. We can distinguish between two main types of assigned business process documentation: - By technical documentation. This describes which technical objects such as transactions, background jobs, programs, user exits, Business Add-Ins (BAdIs) or other extensions are required to perform a business transaction within the context of a business process or business process steps. This information is always up-to-date as the objects are physically available in the managed system and are just referred to in the business process context. - By documents. These documents describe the requirements, design, and realization of business scenarios, processes and steps. These are documents stored directly in SAP Solution Manager. Both types are relevant for Application Lifecycle Management and have to be updated with respect to changes performed during major or minor releases. This document describes ways how SAP Solution Manager can support the procedure to keep the business process documentation up-to-date. It describes the basics of Document Management in SAP Solution Manager as well as the methods based on three best practice use cases. 3

4 2.0 Method and Prerequisites How SAP Solution Manager will be used for Application Lifecycle Management depends on many factors. How daily changes in the system landscape have to be documented and identifying where changes to the organizational structures will be performed both have a direct impact on the method and configuration of SAP Solution Manager. The following chapters explain how to deal with these situations focusing particularly on documentation activities. Topics around documentation of variants but also general information about techniques and possibilities for Document Management are highlighted to establish an information basis for the use case discussion which begins in Chapter Document storage in SAP Solution Manager Technically, SAP Solution Manager uses the Knowledge Provider (KPro) to store all documents which are created within or uploaded into the system. The use of KPro also influences the techniques how documents are stored (Figure 2.1-1). When creating a document in SAP Solution Manager, the system creates two objects: o Logical representation of the document (LOIO): A unique ID which describes and identifies the document in SAP Solution Manager o Physical representation (PHIO) which is created for the LOIO whenever the document or its attributes are changed or translated. The list of PHIOs fills the history tab of the document attribute popup. Ultimately from an SAP Solution Manager perspective, all documents are stored and organized by a Business Process Hierarchy. This hierarchy can be built in projects or in solutions. Figure Relations between logical and physical objects Figure Knowledge Warehouse integration document copy. This behavior is called late copy. All documents in SAP Solution Manager are stored in Knowledge Warehouse (KW) and organized in so-called KW Folders (Figure 2.1-2). Typically, there is a one-to-one relation between a KW folder and a project/solution. In general, a document is stored in one KW Folder but it can be referenced by other KW folders. It is possible to change the document content in the original folder as well as from the referenced side. The situation changes when the documents are created in a different KW Enhancements. This will be the case once you decide to create a project in a different KW Enhancement rather than KWCUST Release 620. In this case, the linked document will be exclusively changeable from the original folder (project/solution) but not from the linked place. Should you change the document from the linked place the system will create a In case the documents are stored in different KW Enhancements, we can achieve a real persistent linkage and thus allow changeability from the original and linked place by the so-called Reference KW Folder functionality. For more information, please refer to the chapter 3.3 Template as single source of truth or to the SAP Note

5 2.2 Document types SAP Solution Manager provides the possibility to standardize documentation by using certain document types and templates. A document type is determined according to its content; for example, ones with a technical or a functional specification. Behind every document type, you can upload a customer-specific document template which gives the document type a custom-specific design. This design appears as soon as a new document based on a document type is created directly in SAP Solution Manager. The following table gives a proposal which document types might be required to document the business processes. It highlights also the place (tabs in SOLAR01/02) where the documentation should be assigned. Document Type Description Structure Tab ZBPD Business Process Description Business Process Gen. Documentation ZFSP Functional Specification Business Process/Step Gen. Documentation ZCON Configuration Description Business Process/Step Configuration ZTSP Technical Specification Business Process/Step Development ZTD1 Test Case Description Step Test Cases ZUT User Training Step Training Material ZINT Interface Description Interface Step Gen. Documentation ZTDS Test Data Sheet Business Process/Scenario Project Documentation Figure 2.2-1: Customer document types The document types mentioned above are examples. Different document types can be created to suit different documentation requirements. Recommendation: Define and use customer-specific document types created in a customer name space. 2.3 Status schema and digital signature The possibility to create status schemas in SAP Solution Manager provides the ability to specifically change status values in a predefined order. This order can vary from document type to document type. Once the decision has been made to use new status values and status schemas, it is recommended to assign a status schema to all document types. This will prevent the users from seeing all status values available in the system except those which are part of the status schema assigned to the particular document type. In the status schema you can specify: - Status values which are part of the status flow - Specific order in the flow - Initial status (automatically proposed by the system during document creation) - End status (locks the document content once the status value is set). This function is particularly useful when the document is prescribed to follow a specific workflow with approval steps 5

6 Recommendation: All status schemas should end with a common released status. - Digital signature as necessary to set a specific status value within the status schema. By using the digital signature, only authorized persons are allowed to set the status value in initiating or finishing the approval of the document. Recommendation: When using Digital Signatures the number of described ALM use cases will get restricted to the One project as single source of truth. The reason is that the copy of documents does not keep the signature and copied documents are unsigned on the end. 2.4 Customer attributes for documents SAP Solution Manager provides the option to setup and use different customer attributes for documents. These attributes can identify the owner of the document for a specific organizational unit (org. unit) or area or it could specify a unique number of bundling documents into a group. This significantly speeds up the reporting and work list creation. 2.5 Automatic generation of a Blueprint, Configuration Guide and Test Report. SAP Solution Manager provides the capability to generate based on available process documentation from the following documents: Document Description Execution Path Blueprint Document Collects content from all blueprint-relevant documents stored for business process hierarchies on the Project Documentation tab (a document can be flagged as blueprintrelevant on his attribute popup). After the collection you can start a standard Macro SAP_BUSINESS_BLUEPRINT which builds the content of the blueprint document. The file will be stored locally and can be uploaded into SAP Solution Manager if needed. Transaction: SOLAR01 Menu: Business Blueprint Generate Blueprint Document Configuration Guide Test Report Similar to the business blueprint you can also create a collection of all configuration documents in one big project- related configuration guide. The Generate Configuration Guide activity considers all documents stored on the Configuration Tab. The processing is done locally by using the Macro SAP_CONFIGURATION_GUIDE. Collects the test status and all test notices in the test phase. The report collects the information from test cases collected in a test plan and builds the information together by executing macro SAP_CREATE_TESTREPORT. Transaction: SOLAR02 Menu: Configuration Generate Configuration Guide Transaction: STWB_2 or SM_WORKCENTER for Test Management Menu: GoTo Create Test Report 6

7 Recommendation: Consider possible design changes on the Business Blueprint,- Configuration Guide,- and Test Report template format. Please follow therefore the technical configuration. 2.6 Documentation process and responsibilities Before starting the ALM design, the general documentation process has to be designed and established. These processes are tool-independent and define the responsibilities and tasks in documentation management. The highest priority of these procedures is to keep the documentation up-to-date throughout the entire Application Lifecycle. Translated to tools like SAP Solution Manager, this will also influence the authorization concept for all people or groups involved in IT processes. From the SAP Solution Manager perspective, we have the following groups and responsibilities: - ALM Governance Group: this group defines the ALM standards for the following: o Basic SAP Solution Manager configuration o System Landscape maintenance o Definition of ALM standards (document types, templates, status values etc.) o Definition of authorization concept - Business Process Owner/Expert: owns the business process with all its documentation and is responsible for approving change requirements/changes, actively takes part in Quality Gate checks and merges documentation. - Business Process Expert/Developer: responsible for implementing requirements and documents all changes within Solution Documentation. The graphic below shows the typical tasks during the documentation management process. Figure 2.2-2: Customer document procedure and roles Work lists in SAP Solution Manager can be created based on: - Change Request Management integration (please refer to chapter 3.1) - Dedicated user assignments to the document: the document owner attribute has to be changed to the next processor of the document. Together with suitable status values, (like for processing, for approval ) the detection of a work list of the appropriate roles can be selected by the evaluation transaction SOLAR_EVAL. 7

8 3.0 Usages The following use cases give an insight into the possibilities how to manage Application Lifecycle Management in SAP Solution Manager from a business process documentation perspective. All cases are based on the pre-discussed business process design (please refer to the ALM Architecture design document). 3.1 One project as single source of truth One project as single source of truth offers a stable single place to document all business processes -- those in production, in plan, as well as those in maintenance. The business process and thus also the documents will reside in this one project in SAP Solution Manager. This fact offers diverse options for document handling from a storage and authorization perspective. In general, the documentation will be stored within different tabs of a project following the logic provided in the Figure However, how the documentation will be handled and how the content will be designed differs from other use cases. In general, all documents used for this case are composed of two main parts: - Persistent area which describes the current production system behavior (existing and live processes / functionalities). For example: the design specification for a business process step describes the current transactional design and behavior; the test case provides how to test the functionality running in the production system. - Temporary area is a location that is only available within a major release project. Within this area, all changes made to the document will be noted and temporarily stored for the time duration of the release project. Before the release project activities end, the temporary area has to be moved to the persistent area. This is to be performed by the business process expert/owner for all documents in his/her responsibility. The procedure can be supported by a Change Management procedure from the beginning of the major release. Change Management procedure: During the approval procedure of a change request, all relevant documents from the appropriate business process can be highlighted and linked directly to the change request by the business process owner. After the approval, the developer takes over the processing of the change in which all required documents have already been linked. During this processing, the change remains as the only gate for the developer to enter the managed system, which then, develops and updates the assigned documentation. After successful testing, the change can be finally approved by the business process owner. During this approval, all changes on all relevant documents can be reviewed and the change released. This will initiate the transport management to finalize the change. The information provided above is also valid for all other types of projects which will be centrally documented in the single source of truth (e.g. Implementation or upgrade). The documentation management is supported in this use case through the following tabs: - General Documentation (In case the single source of truth is a template project) - Project Documentation - Configuration - Development - Test Cases - Training Materials Figure 3.1-1: Document change in maintenance Document management during maintenance Changes on the business process documentation during maintenance phase are reflected directly in the main documentation project. All documents can be changed and stored directly in SAP Solution Manager. To 8

9 lock a specific document for other changes, it can be checked out to a local desktop for content changes. See Figure During this operation, the document is available for all other users in display mode and the system will identify which user has sole use of the document. After the change has been documented, the document can be checked into the appropriate business process structure and subsequently the document stored in SAP Solution Manager will be updated Document management during major release. Major releases as well as roll out projects are concurrently accessing the same documentation but updating different project specific chapters of the document. In these chapters the projectspecific change scope will be documented (Figure 3.1-2). The changes to the document content in the specific release or implementation chapter have to be approved at the end of the release/implementation phase and moved to the persistent content of the document. The usage of only one central storage place for the business process documentation sometimes results in concurrent access to documentation. Figure 3.1-2: Document content changes during major release or roll out Such a situation could be a change from a project and maintenance perspective. To avoid a mix-up and uncoordinated development of document content it is recommended to: - Use specific document chapters to reflect different activities. Almost all document types (excepting test cases) should contain a stable content core which describes the current productive process or transactional design. In addition, there should be different chapters describing the deltas developed during maintenance and roll out or release projects. After the release or roll out content has been transported to the productive environment, the appropriate chapter content should be moved as well to the stable document core. By using this method, the order of changes is always clear and shows the current flow of the design. The exception of test cases is founded in the fact that the roll out or release can produce different ways of testing. During that time, the old or original test case remains available. - Re-use or link the same document in several places as often as possible. As documents remain at the same place and never leave the project, a permanent linkage of documents between structures can be created. Whenever the original document is changed, the changes will become visible for all occurrences across the process hierarchy. An example of such a shared documentation could be a development or configuration documentation for user exits or BAdIs used for several different business processes/steps. - Lock documents by setting the final status value. In this case, the last status value ( release ) will lock the document content; no changes will be possible to the document content or its attributes. A change to this document can be requested by the business process owner who unlocks it for this event. This changes the document status automatically to the initial status value (in case an initial status value has been setup in the status schema). By setting the new processor name in the field Owner, a working list can be created. Following this procedure, it is guaranteed that the status schema will be passed through as designed. - Use keywords for test case documents to make the content of the document visible while filtering criteria during test plan creation. The information about the release or organization unit can be used to test specifically in combination with structure attributes as to what is relevant and is in the scope for a specific test phase. - Use customer attributes for documents to describe business process characteristics e.g. country relevance of developments or process flow/descriptions. This will allow you to report more specifically on the documents collected in the single source of truth. 9

10 - Use local document check-out functionality to lock the document content and inform about current processing in this area. In analogy to the ABAP objects, the person who checks out the document locally to his PC will lock the document content. This will allow making changes in this document also offline. During this process, concurrent accesses are not allowed and the system will identify who is locking the document. - Optionally, use additional KW folders to restrict accessibility to business process documentation. For further details, please consider the information provided in the chapter 4.0 Authorizations in Document Management. With respect to business process structures it is recommended to: - Extensively, use structure attributes (e.g. Status on the Administration tab in SOLAR01/02) to maintain the processing status of the business process (e.g. under release construction ; ready for test, and so on) - Optionally use the project team member assignments as an authorization restriction. By assigning team members to the business process hierarchy you can define a fixed group of people who are allowed to change documents and other objects on the tabs for a specific hierarchy area. Very common in this context is the assignment of groups to business process structures reflecting their main focus (for example SAP Application Component). In this case, only those persons assigned to the business process/step are allowed to change content stored on it. Information assigned to the business process hierarchy in which the user is not assigned will be made available to him/her in display mode only. By using this best practice use case almost all governance activities are separated from the SAP Solution Manager tool. There must be a strong Quality Gate control to establish and guarantee consistent quality and permanent update during roll out/release/maintenance activities. In addition, business process ownership should be established to take the responsibility to approve and control changes within the business process documentation. All changes which are performed and transported through the system landscape can be controlled by Change Request Management activated in other SAP Solution Manager projects. These projects are just for transport bundling and are not used to update the business process documentation Summary This best practice is addressed to customers starting with central and overall solution documentation. It is also recommended for customers within a centralized environment focusing on test management or those needing to integrate with modelling tools. As everything is documented in just one central project, the ALM architecture, which means the concept of used projects and solutions, is very easy. You have a real single source of truth with all solution documentation information, one common place to display and change documentation. As the customer has new and old test information in one central place, integration and regression test plans can be created and maintained very quickly. Information changes happen in the same document. Thus, for a major release the customer initially has to add the new information, test and at go live, merge it with the older content. This behaviour causes less transparency to distinguish between productive information and information under maintenance or in planning. There is no tool support to identify changed documents (Compare & Adjust compares documents and other content of 2 separate projects/solutions). To get this transparency the customer has to add status information and attributes to documents. Thereafter, he can filter the project information in project reporting. While you have an easy ALM architecture without the need to roll-back/compare and adjust information between several projects, you should have stronger governance with Quality Gates to control the maintenance of this single project. 10

11 3.2 Solution as single source of truth The documentation management of the Solution as single source of truth use case follows the software change transportation and can be seen as the best integration between the two areas. On one hand, it allows urgent and normal changes to be handled in a maintenance project. And on the other hand, it gives the possibility to decouple the existing solution documentation for major release purposes. Documentation management is supported in this use case through the following tabs: - Documentation (solution directory) / Project Documentation (in maintenance and roll out/major release/upgrade projects) - Configuration - Development - Test Cases - Training Materials Document management during maintenance During the maintenance phase only corrections (urgent changes, bug fixes) or small developments (normal changes) are realized. These have little impact on the business process design but rather on the documentation stored for the business process/step. For this purpose, the solution cooperates with an explicitly assigned maintenance project with activated Check Out/In functionality (Figure 3.2-1). The big advantage of this functionality is the versioning management of documents between solution directory and the maintenance project. So while the document stays unchanged in the solution directory, a new version can be created in the maintenance project. This version is published to the solution directory at the Checking In procedure. Through this process, the original document is replaced by its new version automatically. Figure 3.2-1: Check out of business process step and document change While the business process and its content are not changeable in the solution, every change can be requested, approved and checked out by using Change Management (change request). Without this option, check out can be made in the maintenance project where the content-like documents or other assignments can be changed. Change Management procedure: creating the Change Request directly from the solution directory has the advantage that the business process/step information is already stored in the change request. The approval of this change can use the partner finding rules and the notification capabilities available in Change Request Management (ChaRM). The availability of the business process/step allows not only the navigation to the managed system to fulfill development or customizing activities but also the navigation to the business process/step hierarchy where documentation can be also be adjusted. By governance it can be ensured that no change request is finished without updating the appropriate documentation. The update of the solution directory is performed by a check in procedure which can also be initiated from the change. Without Change Management, the business process/step can be checked out using a one or two step procedure (with or without approval, respectively). 11

12 Possibilities of Check Out/In : - Specific business process step: allows changes on all assignments attached within the step level. New assignments can be done on all available tabs - Specific business process: allows changes to the specific business process level (existing assignments and adding new objects) as well as to all business process steps that are part of the business process. New steps can be created and documented or not required steps can be deleted. - Specific business scenario: allows changes to the checked out scenario (all tabs are available in a change mode). Additionally, it allows the addition or removal of business processes from a specific scenario. Business processes and their steps are not changeable. - Node Business Scenarios : only available tabs can be changed. The main use case is the addition of new scenarios into the solution directory Document management during major release. The concept of documenting major release activities is based on late copy behavior for all documents stored originally in the solution directory (Figure 3.2-2). This means that all documents coming with the business process are to be initially linked between the solution and the major release project (1). This fact guarantees automatic updates of the content in major release whenever the documents get changed during maintenance. Once the documents are changed in major release (2) the system will automatically create a copy of this particular document (3). Figure 3.2-2: Updating of documents during major release You will experience two different document behaviors, depending on the tab where the document has to be changed: - Copy and addition: This behavior is designed for the Test Cases tab exclusively. When the original test case is touched in the major release project the system will create a copy based on the original test case and place it below the original - Replacement of the original document by its copy: This behavior is available for all other tabs in which document storage is possible. Such a behavior is achieved by creating the major release project in a different KW Enhancement than the solution. For more details, please refer to the document Business Process Redesign in SAP Solution Manager Application Lifecycle Management available in Service Marketplace. The creation of new documents during the major release projects also allows detection of changes during the cutover phase with the Compare & Adjust functionality. Please refer to the document How to Guide for Compare & Adjust in SAP Solution Manager Application Lifecycle Management available in the Service Marketplace. 12

13 3.2.3 Summary This use case can be proposed to all customers who need a clear separation between productive, maintained and a planned environment. This leads to a high transparency in the authorization concept and change process, e.g. in the food producing and pharmaceutical industries. The solution is having a common area to display productive processes and their documentation. Urgent changes and minor corrections are done in the assigned maintenance project supported by the check-in/out or the Change Request Management functionality. Process changes and the assigned documentation are developed in separate projects. This leads to a very good transparency, a deep integration of document, test and change management and an easier administration per project/solution. This use case is applicable to the dual system landscape concept. The disadvantage is that the changes in the different projects/solutions have to be identified and retrofitted into the solution. The document change and retrofit process is supported by several tool functions, like late copy or Compare&Adjust. But despite this, the customer would still have a rather complex merge process after a cutover. The more projects/solutions you have the more complex this procedure gets. Further, you have only one assigned maintenance project per solution. All products that are part of this documentation have to follow the same maintenance cycle. Either you are able to harmonize software changes in your company or you get quite a complex ALM architecture. This is also true for the integration of modelling tools. In the use case with only one central project you can clearly distinguish between document management done in the project and business process changes done in the modelling tool. With respect to test management, the big disadvantage is that re-generation of test plans from a solution is not possible. That means that after test cases or the process structure have been updated; a completely new test plan has to be created for your integration or regression tests. So for customers with strong focus on time-efficient test management, this use case is not recommended. 13

14 3.3 Template as single source of truth The template project as single source of truth follows the main idea of Template Management in SAP Solution Manager. It combines all the methods and functions available, including the possibility of cutover delta information from roll out or major release projects by using the Compare&Adjust functionality. The organization and distribution of business processes in and from the template project (e.g. major release or roll out projects) can be generally organized by two options: - Use of templates: all required business scenarios will be assigned to a predefined template ID. The templates can strictly focus on the SAP modules (components) (e.g Finance or Logistics) or on the functionality (e.g. Order to Cash or Procure to Pay). These templates are then made available to the major release or rollout projects and can be selected from the Scope tab of the new project. This selection copies all relevant (included in the template) business scenarios, processes, steps with all assigned objects (documents and technical objects) to the new project in the background. Procedure: Start transaction SOLAR_PROJECT_ADMIN for a major release/rollout project; select Scope tab Template selection and select appropriate templates. After saving, the system copies the template content into your project. All documents will be linked automatically. - Without template use: only in cases in which no template ID has been created for the Single Source of Truth can you scope the major release or roll out project flexibly. You can scope/copy whole business scenarios or processes from the Single Source of Truth into your major release or roll out project. Procedure: Start transaction SOLAR01 for your major release/rollout project, navigate to the Structure tab; change the content of the field Source from Business Process Repository to Project ; on the pop-up select the Single Source of Truth (template project); select the appropriate business scenario or business process (depending on which level you started the selection). The system will copy the content and ask how to proceed with documents. Select Refer to documents. The Document Management is supported in this use case through the following tabs: - General Documentation (template project): provides generic documents describing business scenarios, processes or steps in their flow, design and functional use. These documents are not directly changeable in roll out/major release projects. Please consider in this context Chapter Document management during major release. - Project Documentation: is used in the template project for internal purposes and is not a part of a roll out or major release project. This tab can be used to manage changes coming from a roll out/major release project and to merge them into the general documentation. In a major release/roll out project this tab can be used to maintain country-specific roll out information or changes in design made during a major release project. Please consider in this context Chapter Document management during major release. - Configuration: provides documentation about scenarios, processes or steps related to specific IMG configuration. - Development: aside from technical objects, it gives the possibility to describe, specify and document the design of your developments. - Test Cases: provides a collection of test case descriptions for all relevant test types and all executable variants. - Training Materials: provides in a template, already predefined training materials describing the usage of the transactions and its different variants from the end-user perspective. You will experience different document behaviors depending on the tab where the document has to be changed and where it is originally stored: - Copy and addition. This behavior is designed exclusively for the Test Cases tab. When the original test case is changed in a major release project then the system creates a copy based on the original and places it below the original. 14

15 - Replacement of the original document by its copy (also called late copy ). This behavior is available on all other tabs (except the General Documentation tab) where document storage is possible. - Reference Folder is a possibility to link documents provided by templates to the rollout/major release project. This means that the original document stored in the template project (1) is changeable not only in the template project but also in the roll- out/major release project (2). This is shown by the Figure In such case, the users who are allowed to change the content must be authorized for the specific KW folder (2). Please refer to Chapter 4.0 Authorizations in Document Management. Figure 3.3-1: Document change in maintenance Document management during maintenance. Changes on business process documentation during maintenance are reflected directly in the Single Source of Truth (Figure 3.3-2). All documents can be changed and stored directly in SAP Solution Manager. To lock a specific document for other changes it can be checked out to a local desktop for content changes. During this operation, the document is locked for all other users. The system informs others which user currently locks the document. After the change has been documented, the Figure 3.3-2: Document change in maintenance. document can be checked into the appropriate business process structure and automatically, the document stored in SAP Solution Manager is updated Document management during major release. The document management for the major release project is based on the standard document behavior between template project and rollout project. This means that almost all documents provided by the single source of truth are initially linked to all consuming projects like roll out or major releases (1). They are signed for late copy. The exceptions here are all documents stored on the General Documentation tab as well as all documents stored in a KW reference folder (see Figure 3.3-1). The system prevents making changes to the original documentation and forces a copy creation once it is intended to edit the document in the rollout/major release project (2). The copy of the document allows separating the document content for the existing functionalities and functionalities being developed/changed by the new project (3). Note however that the system always recognizes this copied document as a new version of the original. The new information will be especially relevant when cutting over the documentation into the single source of truth. There is a detailed description in the Compare&Adjust How to Guide (link). Figure 3.3-3: Document change in roll out/major release. 15

16 Changing documents stored on the General Documentation tab The General Documentation tab provides documentation which is not directly changeable in rollout/release projects. However, in some situations the documents have to be changed, for instance, in case the business process design or transaction will follow a different design. In such a case, the appropriate document has to be linked to the Project Documentation tab. As long as the document is not edited on the Project Documentation tab all changes done to the original document during maintenance will be visible also in rollout/major release projects. At the first attempt to change the linked document or its attributes, the system will automatically create a document copy (late copy). As of now, the new process information (changes to design or behavior of the process step or transaction) will be included in this new document copy. During that time, the original document is still available in its original state on the General Documentation tab. The cutover of the information about the changed process, step or transaction design into the Single Source of Truth is guaranteed by the Compare&Adjust functionality. This functionality will detect changes and allow these to be brought into the template project. However, these new documents will be cutover to the Project Documentation tab of the template project and remain private (to the template project) unless they are harmonized (from content perspective) with the documents stored on the General Documentation tab. Please Note: If you use the global rollout functionality and global attributes, all blueprint-relevant documents stored on the General Documentation tab will be copied per default to the Project Documentation tab of the major release/rollout project. This may lead to an issue in the cutover phase. As all documents, also unchanged ones, are now stored on the project documentation tab, they will be rated with a delta. By using Compare&Adjust all of them will be detected and potentially brought back to the template project. This behavior can be suppressed using the BAdI CL_SA_DEFINE_GLOBAL_ATTR. In the method CHECK_GLOBAL_ATTRIBUTE you can deactivate this behavior by initializing the parameter copy_blueprint_docs_to_proj_do = ' ' Summary This alternative can be treated as an extension of the first use case, with one central project. It is most suitable for customers having a single or a dual system landscape and a central documentation. The solution documentation is represented by a combination of a template project, roll out and/or major release projects and has a close integration to Change Request Management and Test Management. This use case combines the advantages of the two use cases beforehand. There is a clear separation of general and project documentation. Via template test plans, it is possible to have an additional integration between documentation and test management. Test plans can be updated with delta information. The integration with modeling tools is still rather clear. The integration with Change Request Management is a compromise between both use cases. You have good transparency and separation of productive and planned processes, but less strict integration in maintenance. The disadvantage of harmonization needs is not as big as in the central solution use case beforehand, but there is still a complex merging of documents after cutover into the template project (especially for General Documentation tab). 16

17 4.0 Authorizations in Document Management 4.1 Restrictions between projects To restrict access to different projects, the authorization object can be used. Depending on the number of implementation projects it is possible to: 1) Assign a specific project ID to the authorization object S_PROJECT (PROJECT_ID Project name) and assign this authorization to the project team members. 2) Work with a predefined namespace for projects (e.g., projects used by a specific organizational unit will use a predefined prefix for project IDs). Afterwards, you can provide the prefix in the authorization object S_PROJECT and use it for several project teams. Authorization objects S_PROJECTS and S_PROJECT can be found, for example, in the role SAP_SOLAR_PM. Please copy the role to a customer namespace and set it up based on your requirements. 4.2 Restrictions within a project structure The setting "Restrict changes to nodes in project to assigned team members" can be activated in SOLAR_PROJECT_ADMIN on the Team Members tab. This will allow changes to structure nodes in SOLAR01/02 where the users are assigned from the Administration tab. All other nodes will only be accessible in display mode. If you check this box, only team members who are assigned in the Administration tab can work on the nodes of a project structure. Other team members can only open the appropriate tabs in display mode. You need to change the authorization for the tab (authorization object AI_SA_TAB) to enable assigned team members to work on the specific tab. 4.3 Restrictions within the document management (different KW Folders) You can use different KW folders within one project. One KW folder can be assigned to exactly one folder group. The authorization for all included documents is checked against this folder group. Please follow the description below to set these up in your system. 1) Start transaction SI23, for the area SAP Solution Architect, and go to the menu Settings Folder Groups. In this view, you can create a folder group for the new folder. 2) Afterwards, start transaction SI80 and select the folder in which the folder group will be changed. Go to the menu Folder Attributes Change (the context where you currently are should be equal to the original context in the attributes of the folder; otherwise, it will not be possible to change the folder group). Now you should be able to choose the folder group (created in step 1), using F4-help. Alternatively, you can create a new KW folder and assign the folder group to it. 3) The folder group can be assigned to the authorization object S_IWB. The parameter IWB_FLDGRP is usually equal to the project name of the folder created by the system during project creation. Afterwards, you should be able to move special "top secret" documents to the newly created folder, using the Attribute popup of the document and the button Replace Folder. Alternatively, the assignment is also possible when saving the document using the method HANDLE_EXIT_BEFORE_SAVE, class CL_SA_IO_DOC, and using KW function modules. 17

18 4.4 Standard authorization roles This chapter provides information which authorization roles are available for the main solution documentation transactions Project administration (SOLAR_PROJECT_ADMIN) In general you can use the predefined composite roles (technical abbreviation: *_COMP) for following user groups: 1) Project Manager (technical role name: SAP_SOL_PM_COMP) 2) Application Consultant (technical role name: SAP_SOL_AC_COMP) 3) Technical Consultant (technical role name: SAP_SOL_TC_COMP) 4) Development (technical role name: SAP_SOL_BC_COMP) 5) Display User (technical role name: SAP_SOL_RO_COMP) Authorization Roles SAP_SOL_PROJ_ADMIN_ALL SAP_SMWORK_BASIC_IMP SAP_SMWORK_IMPL Description Full authorization for project management Basic authorization for the Implementation and upgrade work center Authorization for the Implementation and upgrade work center SAP_SOL_PROJ_ADMIN_DIS ** Display authorization for other users such as Application consultant SAP_SMSY_ALL Full authorizations you need for maintaining the system landscape in transaction SMSY that includes logical components. For more info, please refer to link: SAP Components SAP Solution Manager <current release> Operations Business Blueprint (SOLAR01) Application consultants are responsible for making sure that the business blueprint and software configuration are tailored to the business processes and that analysis and report requirements are fulfilled. Application Consultant (technical role name: SAP_SOL_AC_COMP) The table underneath gives you a further details regarding some of the single roles which are required, also included in the Application Consultant composite role Authorization Roles SAP_SOL_PROJ_ADMIN_DIS SAP_SMWORK_BASIC_IMP SAP_SMWORK_IMPL Description Full authorization for project management. Contains full authorization for work center - related functions for implementation. Allows access to the implementation and upgrade work center 18

19 SAP_SOLAR01_ALL SAP_SUPPDESK_CREATE SAP_SOL_KW_ALL SAP_SMSY_DIS Contains full authorization for business blueprint (transaction SOLAR01). Allows you to build your business processes and steps. Full authorization to create a service desk message when the following functions are used: o Roadmap o Business Blueprint o Configuration Contains full authorization for Document management within transactions SOLAR01, SOLAR02, and SOLMAN_DIRECTORY (Knowledge Warehouse folders) Contains display authorizations for the system landscape in transaction SMSY that includes logical components. For more info, please refer to link: SAP Components SAP Solution Manager <current release> Operations Configuration (SOLAR02) Application consultants are responsible for making sure that the business blueprint and software configuration are tailored to the business processes and that analysis and report requirements are fulfilled. Application Consultant (technical role name: SAP_SOL_AC_COMP) The table underneath gives you a further details regarding some of the single roles which are required, also included in the Application Consultant composite role Authorization Roles SAP_SOL_PROJ_ADMIN_DIS SAP_SMWORK_BASIC_IMP SAP_SMWORK_IMPL SAP_SOLAR02_ALL SAP_SUPPDESK_CREATE SAP_SOL_KW_ALL Description Contains full authorization for project management. Contains full authorization for work center - related functions for implementation. Allows access to the implementation and upgrade work center. Contains full authorization for business blueprint (transaction SOLAR01). Allows you to build your business processes and steps. Full authorization to create a service desk message when the following functions are used: o Roadmap o Business Blueprint o Configuration Contains full authorization for Document Management within transactions SOLAR01, SOLAR02, and SOLMAN_DIRECTORY (Knowledge Warehouse folders). 19

20 SAP_SMSY_DIS Contains display authorizations for the system landscape in transaction SMSY, which includes logical components. Development consultants work with the project manager and the application consultant on the planning and organization of the authorization concept. They also perform developmental tasks and customer-specific developments. Basis/Development Consultant (technical role name: SAP_SOL_BC_COMP) The table underneath gives you a further details regarding to some of the single roles which are required, also included in the Application Consultant composite role Authorization Roles SAP_SOL_PROJ_ADMIN_DIS SAP_SMWORK_BASIC_IMP SAP_SMWORK_IMPL SAP_SOLAR02_EXE SAP_SUPPDESK_CREATE SAP_SOL_KW_ALL SAP_SMSY_DIS Description Contains full authorization for project management. Contains full authorization for work center - related functions for implementation. Allows access to the implementation and upgrade work center. Contains full authorization for business configuration (transaction SOLAR02). Allows you to add all necessary configuration information to your business processes and steps. Full authorization to create a service desk message when the following functions are used: o Roadmap o Business Blueprint o Configuration Contains full authorization for Document Management within transactions SOLAR01, SOLAR02, and SOLMAN_DIRECTORY (Knowledge Warehouse folders). Contains display authorizations for the system landscape in transaction SMSY, which includes logical components. For more info, please refer to link: SAP Components SAP Solution Manager <current release> Operations 20