Purchasing an expensive vehicle compels the owner to protect his or her investment with regular maintenance checks and timely service. An inherent trust and dependence is placed on the service technician to access the diagnostic instructions, technical diagrams, and maintenance checks to properly service the vehicle. Investing in SAP systems requires the same due diligence to protect the investment. Leveraging new functionality and upgrading when necessary are part of properly servicing the SAP system. But does the IT department have access to what it needs to perform this service?

Many IT organizations no longer have access to the original design documents that were created during the initial implementation. Moreover, continuous change to the SAP systems outdates the original design. Individual project teams generate and organize documentation according to the deliverable requirements for the project. Without centralized access to the SAP design documents, companies incur unnecessary costs in the redundant duplication of various materials, inhibiting knowledge transfer to new hires and contractors and preventing IT from flexibly adapting their SAP systems to changing business requirements or upgrading to newer releases.

SAP Solution Manager is designed to provide companies with a process-oriented storage device for key documents. The Business Blueprint structure links the components of business processes together, including design documentation, SAP transactions, configuration documentation, SAP IMG objects, test scripts, and training materials. The Business Blueprint approach to document storage is a centralized framework designed to assist project teams in the definition and build activities, for seamless knowledge transfer to the support organization at go-live, and for accessibility by the support team for on-going support and maintenance — ensuring the ability to properly service the SAP systems. I’ll outline the key considerations for architecting a document strategy for SAP Solution Manager.

Plan What to Store, Where to Store It, and How to Store It

The key to a good documentation strategy is to start by planning what to store, where to store it, and how to store it. After planning, document the defined standards and procedures, and then publish and communicate the strategy to all participants to ensure a disciplined, consistent approach. Document repositories that have not been properly architected can prevent the IT organization from realizing its original objectives.

At minimum, SAP recommends that all solution application documentation be stored in SAP Solution Manager. Other documentation used strictly for individual project management can either be stored within the roadmap or in an offline repository.

The SAP roadmap functionality offers methodology for project management under various SAP scenarios (e.g., implementation, upgrade, and global rollout). A roadmap can be selected for the project, and then project deliverables can be uploaded and stored in the roadmap for the project. However, if an internal project methodology has been adopted, then an offline repository is more appropriate for storing these types of documents. If the documents are specific to the definition, build-out, and maintenance of the SAP solution, then they should be stored in the Business Blueprint structure for the project or solution. However, you can store meeting minutes, risk assessments, and other project-specific documents offline in a Microsoft SharePoint site, shared network file system, or other storage medium.

The fundamental standards that must be defined and communicated prior to storing documents in SAP Solution Manager can be broken down as follows:

• What to store?
  • Customize documentation types based on the internal methodology
  • Determine document status values and status schemes
• Where to store it?
  • Build the Business Blueprint structure
  • Outline the document storage guidelines (part 1)
• How to store it?
  • Define the document naming convention
  • Outline the document storage guidelines (part 2)

  • Identify keywords to enhance reporting and identification of documents

Customize Documentation Types Based on the Internal Methodology

All documents created in SAP Solution Manager are assigned a documentation type, which is used to categorize documents for easy retrieval as well as to ensure consistency in producing like documents. SAP includes standard documentation types and templates that are used for SAP documentation delivered by the Business Process Repository (BPR). First, create custom documentation types based on the internal methodology used. Then design templates for each documentation type and upload them into SAP Solution Manager. 

At a minimum, documentation should be stored to outline all master data and organizational unit requirements, business process procedures and flow diagrams, configuration changes, test scripts or validation documents, functional specifications, and development or technical specifications.

Custom documentation types should follow the SAP system requirement and begin with Y or Z. Prefix the name of all custom documentation types (i.e., the description) with a corporate acronym. This makes it easier for selecting the right documentation type when creating documents. The custom types naturally group together if a prefix has been attached to the beginning of each name. For an example, see Table 1.

Table 1

Example custom documentation types

However, if the wrong documentation type is assigned to a document, it can (and should) be changed in the Maintain Attributes window for the document. You can access this window by clicking the attribute icon from the documentation toolbar (Figure 1). Here you can maintain the document Title, Documentation Type, Status, Priority, Person Responsible, blueprint relevancy (Business Blueprint-Relevant check box), and Keywords.

Figure 1

Click the attributes icon to maintain attributes in the pop-up screen

Documentation types are customized in the project administration transaction SOLAR_PROJECT_ADMIN. Additional features of documentation types include:

1. Global: Indicates if the type is included in all projects or selectively included
2. Several: Whether more than one document of the type is allowed on a tab
3. Extension: If a template is not provided, indicates the application to launch
4. Blueprint-Relevant: Whether the type is included when generating a blueprint. Blueprint relevance can also be set in the attributes of the document.
5. Status Scheme: Discussed in detail in the following section

Determine Document Status Values and Status Schemes

Status values assigned to documents are defined in the IMG. You can use standard-delivered document statuses and configure additional statuses. You can define status schemes and use them for a particular document type or types. For example, a status scheme appropriate for the blueprint documents may be different from a status scheme appropriate for configuration and development documents.

Implement a statusing process that fits within the internal methodology, and include the SAP-delivered status values if possible. It’s a modification to the standard if these statuses are removed. Status schemes provide additional control by forcing a structured approach to define the valid sequence of status values that can be assigned to documents.

Build the Business Blueprint Structure

The Business Blueprint structure represents the SAP-standard business processes that have been implemented, as well as custom development used to address gaps in standard functionality. Both SAP and non-SAP business processes and business process steps should be documented in the Business Blueprint.

There are a few ways to build the Business Blueprint structure for a defined project in the SAP system:

1. Build the structure by manually selecting content directly from the BPR
2. Manually create a custom structure, or add elements to a structure created from the BPR content (for custom tables, custom processes, and custom process steps)
3. Reverse business-engineer the Business Blueprint by automatically generating it from usage statistics using a third-party tool

Building the structure without a third-party tool can be cumbersome. With SAP Solution Manager 7.0 with enhancement package 1, SAP provided the Solution Documentation Assistant to help tailor the structure, but it is only based on transactional usage statistics. You must define additional content manually.

A third-party tool analysis can provide a reverse business-engineered blueprint that includes additional standard SAP transactions that are not delivered by the BPR content. This type of analysis combines transactional usage with customizing and table data usage statistics for a more accurate understanding of the processes used in SAP systems.

Outline the Document Storage Guidelines — Part 1

The Business Blueprint structure offers six locations for document storage: three primary levels and three supporting levels (or nodes).

• Location 1 is the Project node
• Location 2 is the Organizational Units, Master Data, and Business Scenarios nodes at the project level
• Location 3 (primary level 1) is the specific organizational unit, master data, or scenario structure element at the project level
• Location 4 is the Organizational Units, Master Data, and Business Processes nodes at the scenario level
• Location 5 (primary level 2) is the specific organizational unit, master data, or business process structure element within the scenario
• Location 6 (primary level 3) is the business process step

You can assign documents directly to transactions by following menu path Business Blueprint Structure > Implementation Project > Business Scenarios > Sales and Service Processes in ERP > Business Processes > Account Processing in ERP (Figure 2). Then you go to the Transactions tab, use the attribute icon, and assign the document on the Links tab.

Figure 2

Assign documents directly to transactions

You can store documents on the Proj. Documentation tab for all six locations of the structure, and on the Gen. Documentation tab of template projects (i.e., projects with the project type set to template). You can also store documents on the Configuration and Development tabs, but only at the primary levels where there is a specific structure element defined (i.e., these types of documents don’t make sense attached at a node level).

Decide where to store which documents by document type. For example, create Business Process Procedures at primary level 1 attached to the specific business process structure element. You can create configuration documents on the Configuration tab with a 1:1 relationship to the IMG object or one per tab.

You can set visibility to the tabs by using transaction code SOLAR_PROJECT_ADMIN. From the main screen, select the Project Standards tab, then Tabs, and set visibility according to the Blueprint and Configuration environments. 

Define the Document Naming Convention

To ensure subsequent identification of documents in the Knowledge Warehouse (KW) database, it is important to define a naming convention for all documents and then consistently follow it.

There may be cases in which the link of an individual document is lost and must be reestablished. Using the Find Document functionality with a pre-defined naming convention, together with the documentation type, can facilitate this process.

SAP provides a guideline for naming documents according to the company’s business process model shown in Figure 3.

Figure 3

Sample naming convention

The naming convention should become intuitive. Avoid over-engineering this — define a standard that makes sense to the team.

Another advantage to consistency in the naming convention for documents stored in SAP Solution Manager is that it is easier to establish the context of the documents outside of SAP Solution Manager. All documents stored in SAP Solution Manager are downloadable. If the name is standardized, it implies the context (i.e., business scenario, process, and process step) within the blueprint structure. Moreover, reporting of documentation within SAP Solution Manager can be exported to Microsoft Excel — at which point the hierarchical context may no longer be visible.

Outline the Document Storage Guidelines — Part 2

When assigning documents to the Business Blueprint structure, SAP Solution Manager offers multiple options.

You can create documents directly in SAP Solution Manager (according to the template associated with the documentation type), link them to another document in the KW, copy them from another document in the KW, upload them, or link them to an external storage system (such as a Microsoft SharePoint site) via URL.

Uploading documents does not ensure compliance to the template format associated with the documentation type, but makes it more flexible for contributors.

Outline the acceptable practices for storing documents according to the documentation type. Define which types must exist in the SAP Solution Manager KW, which types may be links to external storage systems, and the policy for linking documents within the structure (i.e., for common process steps).

Identify Keywords to Enhance Reporting and Identification of Documents

Keywords are defined during the Project Preparation phase as they can be used to differentiate structure elements of the Business Blueprint as well as documents. Keywords are assigned to documents using the attributes icon.

The use of keywords at the document level is at least necessary to differentiate development documents by the type of development: workflow, report, interface, conversion, enhancement, form, and modification.

Avoid having too many keywords (more than 10). Too many keywords can confuse the teams when maintaining too many attributes. You can also assign keywords to documents as further selection criteria in reporting (transaction SOLAR_EVAL).