The Knowledge Warehouse inside Solution Manager is a tool for managing and serving content for your enterprise. However, most users of Solution Manager only take advantage of a small portion of what this functionality can do.

For the most part, when an enterprise uses Solution Manager for its implementation capabilities, document management is only touched upon using the control icons found on the tabs in transaction codes SOLAR01 and SOLAR02. However, by understanding how the Knowledge Warehouse organizes and stores data, you can do much more than simply create, edit, and check documents out or in.

Opportunities include (but are not limited to):

• Downloading documents in mass for a “point-in-time snapshot” or offline access purposes
• Making documents available to users outside of Solution Manager without their needing a Solution Manager user ID or even the SAP GUI
• Grouping documents for access control via authorizations
• Leveraging solution documentation to improve context-sensitive help

As with most highly capable software products, the Knowledge Warehouse has its own set of terms that need to be understood in order to take advantage of the capabilities of the application. Let’s take a look at a few of these.

Information objects come in two basic types: content objects and structure objects.

Content objects contain content such as text, graphics, or even audio-visual content. They are stored in the Knowledge Warehouse primarily as binary large objects (BLOBS), but may also consist of XML or HTML content.

Structure objects are hierarchical links to other information objects. These provide the ability to organize content into groupings that are of a parent/child nature. Structure objects support links to content objects or other structure objects. Linking to other structure objects provides capabilities for structure re-use as well as nesting to form more complex organizational structures for collections of content objects.

For more detail see SAP Help at https://help.sap.com/saphelp_sm71_sp12/helpdata/en/75/d71948614711d3b0ca0000e8a4b41d/content.htm.

Another term is documentation. It is a technical as well as a literal term in Solution Manager.

The literal interpretation of documentation represents physical documents stored in Solution Manager such as process designs, functional and technical specifications, test scripts, and training materials. The documents can be stored on almost every tab within the Solution Manager Business Process Hierarchy (BPH).

The technical form of documentation in Solution Manager is the collection of technical and component information that is assigned to the BPH. This information identifies the technical objects that are used in the building and delivery of the solution. By assigning these to the BPH, the objects are organized relative to the business processes they support and enable. Examples include:

• Transaction codes (Transactions tab) – These links invoke the transactions in the managed systems. Figure 1 shows other objects that can be assigned to the Transactions tab.

Figure 1

Object types on the Transactions tab

• Configuration objects (Configuration tab) – This tab allows you to map configuration objects and other technical components to the business processes and steps. Figure 2 shows the different types of technical objects that can be assigned to the Configuration tab.

Figure 2

Object types that can be stored on the Configuration tab

Other tabs that store non-document documentation include the Testing, Development, End User Roles, and Business Functions tabs. Covering all of these in detail is beyond the scope of this article.

Attributes of Documents in the Knowledge Warehouse

The Knowledge Warehouse maintains information about the documents stored within it. This information is referred to as attributes or metadata. These include, but aren’t limited to the following:

• The LOgical Information Object (LOIO) is a unique identifier for the container that holds all the versions of a given document in the Knowledge Warehouse. You can think of it as a folder in a filing cabinet. For example, you might have a folder in your filing cabinet called Resume. In it, you could have any number of versions of your resume. In this example, the LOIO would be Resume, the unique identifier of the folder that holds your resumes.
• The PHysical Information Object (PHIO) is the unique identifier for each version of the document stored in the LOIO. In the example above, each version of your resume would have its own unique PHIO.
• Standard and custom attributes are characteristics or metadata about the document that aren’t used to locate and manage their storage, but rather help describe the document. Solution Manager comes with several standard attributes such as title, status, person responsible, and keywords, and also supports creating additional customer-specific attributes. These attributes can be assigned to both the LOIO and PHIO classes in configuration to control how they are tracked in the version history. Attributes assigned to the PHIO class maintain version history of the attribute values each time a document is changed or versioned. For more information on custom attributes and version history see my article “Improve SAP Solution Manager Reporting Capabilities by Using Your Own Custom Document Attributes.”

Obviously, this does not cover the complete list of terms associated with documentation management in Solution Manager, but it covers enough for my purposes in this article.

Projects

During the design and build phases of an implementation, projects are the primary way to manage documentation. Projects offer a great many options for managing content, and provide the high degree of flexibility required during these phases of an implementation.

The two primary types are template and implementation. In general, template projects are used when building or maintaining the global template for your enterprise. The global template is the collection of processes that are to be used in a standardized way across the enterprise.

Implementation projects are used for each release of your solution. The concept of a release or go-live can be applied when doing global rollouts to different geographies or business units, or if simply releasing a collection of new functionality or enhancements.

The key difference between these two project types from a documentation perspective is the use of the General Documentation tab.

When building or enhancing the global template (template project), the business design and other non-technical documentation are housed in the General Documentation tab. Any documents stored there become visible and available to downstream implementation projects. Any documents stored on the Project Documentation tab of a template project are not visible to downstream implementation projects.

When preparing for a release or go-live, the project team creates an implementation project and populates it by selecting a subset of the BPH content from one or more template projects. When the BPH content is copied into the implementation project, all the documents on the General Documentation tab from the template project appear on the General Documentation tab of the implementation project. However, the documents on the General Documentation tab of the implementation project are display only. This serves to make the template documentation available to the implementation project as a reference only.

At this point, the documentation on the General Documentation tab of both the template and implementation projects are links to the same physical document in the Knowledge Warehouse. In short, the LOIO is assigned to the BPH nodes of both projects. The team working on the implementation (or release) can make a copy of the document to the Project Documentation tab if changes are necessary for the release. This is often referred to as a localization, as the changes are often requirements of a specific geography or business unit and are not intended to be reflected in the global template.

Solutions

In Solution Manager, a solution is much like a project but has a lot of additional features and functionality. As part of preparation for go-live, the project team publishes the content of the implementation or template project to a solution. This copies the project content into the target solution. You can think of the projects (template or implementation) as the work in process inventory, and the solution as the finished goods inventory.

From a Knowledge Warehouse perspective, you have options when you migrate from a project to a solution. You can either copy your content into the solution or reference it. If you choose to reference the content, the documents stored in the Knowledge Warehouse are assigned to the solution. So, as with the template and implementation project relationship described before, there remains only one physical copy of your documents and now the projects and the solution simply point to the same documents.

If you choose to copy the documents, the new physical copies of the documents are created in the Knowledge Warehouse and are assigned to the solution. While there are certain advantages to this (such as the documentation in the solution remains unchanged during the design and build phases of subsequent releases), it does mean that keeping the documentation current as subsequent releases are delivered is a bit more manual.

Both projects and solutions allow for checking out documents, but the solution has the additional feature of being able to check out structure content as well. During the operational or sustain phase, it will be necessary to do break fixes, apply patches, release minor enhancements, and the like. By checking out a portion of the solution, you can maintain all the content (both technical and documentation) related to the business processes undergoing changes independently from the solution. This allows the solution to always represent what’s in production.

Once you’ve made and tested all the changes for the processes affected by the break fix and patch, you simply check in the structure nodes in their entirety to update all affected portions of the solution at once. Throughout this process, the Knowledge Warehouse keeps track of where your documents are referenced by the different projects and solutions, and automatically manages the versions in the background.

Compare and Adjust

Compare and adjust is a functionality in Solution Manager that analyzes changes in an implementation and template project relative to when it was created or the last time it was adjusted. This functionality compares the content of the project against a reference point, either itself, another project, or the SAP Business Process Repository. The comparison highlights what has changed and offers you options of how you would like to reconcile the changes.

A key concept of the compare-and-adjust functionality is the notion of temporary and persistent storage spaces in the Knowledge Warehouse. Projects use the temporary storage in the Knowledge Warehouse and, when the content is published to a solution, the content is migrated to the persistent or permanent storage. This is done automatically for you by Solution Manager, and creates the reference point used by compare and adjust when analyzing changes relative to a production solution.

For more detail on compare and adjust see my following SAP Experts articles:

“Roll In Compare and Adjust 7.1 Enhancements to Your Global Template” and “Demystifying the Global Rollout: Using Template and Implementation Projects to Manage a Global Deployment.”

For more detail on publishing a project to a solution see my article “Cutover to Production From Project to Solution.”

The Knowledge Warehouse Layered-Storage Model

The Knowledge Warehouse uses several logical grouping techniques to organize and manage content. For the most part, Solution Manager is an abstraction layer that spares you the tedium of setting up and managing these logical groupings. However, understanding what they are and how they relate to one another can open up possibilities for getting even more value out of your solution documentation as well as for implementing more robust controls.

In the Knowledge Warehouse, content is stored in enhancements. An enhancement is like a library that can hold multiple folders for arranging and managing content. When a project is created, Solution Manager prompts for the enhancement context within which the project documentation is to be stored. By default, the /KWCUST/ enhancement is delivered in Solution Manager. All roadmap, project, solution, and SAP Best Practice content is stored within it.

Within each enhancement there is a concept of an area. The area definition defines how content is managed within the folders contained within the enhancement. The Document Modeling Workbench (transaction code DMWB) is where the configuration of the area is performed. The default area for solution documentation is IWBSOLAR. See this SAP Help link for more details on which areas, folders, and folder groups are used by default for the different types of documentation in Solution Manager: https://help.sap.com/saphelp_smehp1/helpdata/en/4d/e41b12141f442786b0084d7842a99d/content.htm.

Once you understand where the content is stored for different types of documents and structure content, you can begin tailoring authorizations and roles to give you more access control within your projects. For example, you can create an additional Knowledge Warehouse folder for documentation that is restricted and should only be accessed or maintained by a subset of the project team.

For more details, reference SAP Help - Assign Authorization for Documents.

Solution or Project… Making an Informed Choice

Since projects and solutions have very similar capabilities from a written document perspective, the key things to consider when deciding whether to use a solution or a project is what state your documentation is in and how much change you anticipate over the near term.

A solution is primarily positioned to house finished documentation that represents the “as is” of the production system. As such, changes to a solution should fall under more rigorous control. Solution Manager provides capabilities to support such rigor.

One of the key differences between a project and a solution is how they handle structure content.

Within a project, you are free to make changes to the structure content (assuming proper authorizations) as necessary to accommodate the dynamic nature of the scope in the early stages of a project. This flexibility is monitored through the history reports, but does not provide a great deal of prescriptive control.

A solution on the other hand has the ability to check out structure content and along with it, the associated documentation. This copies both the structure and document content into a maintenance (or implementation) project to be changed and tested prior to releasing it back into the solution.

This concept of check out/in at the structure level allows for changes to be tracked and managed by the business processes they affect. This reduces the level of object management required by the project team implementing the changes because all the objects related to the structure that is checked out are easily identifiable and can be managed as a single unit of work.

This works very well when implementing relatively small changes to business processes, or performing production break fix (such as SAP Notes, patches, and configuration/code changes) and you want to better ensure that all the associated documentation is kept in synch.

Some things to consider (this is not an exhaustive list):

• If you are a large organization expecting to have multiple implementations occurring either simultaneously or in rapid succession, you should consider using both projects and solutions.
• If you plan to use any of the robust operational capabilities of Solution Manager you will definitely want to use at least one solution in your deployment strategy.
• If you have a very small organization or your organization will have a very low volume and rate of change, then a solution by itself may suffice.
• If your intent is to only manage documentation, then projects alone can work well.
• As a general rule, if your organization is a good candidate for a solution (i.e., you wish to control all objects related to a change using check out/in or you want to use the operations features of Solution Manager), you are most likely a candidate for using both projects and solutions.

As always, I advise that you set up experiments in a sandbox or development Solution Manager system as you delve deeper into the details of these capabilities. There’s a lot of control and power in the Knowledge Warehouse, and “With great power, comes much responsibility!” – Voltaire.

D. Russell Sloan

D. Russell Sloan is a specialist in project and program governance for IBM. He focuses on the use of SAP Solution Manager for global rollout projects for IBM’s largest customers, having worked with SAP software since 1996. Russell has degrees in accounting and information systems and has been a team and project leader for SAP projects for more than 14 years. He has been developing and deploying software systems for over 30 years.

You may contact the author at solmanruss@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.