Deciding on the right structure of the project can impact how quickly your project team will begin leveraging Project Administration. If information is not organized logically – project team members may spend more time finding where they need to be working rather than on the actual work. Additionally, the quality and amount of information you store in Project Administration directly affects your ability to leverage other tools in Solution Manager later on. These other tools include Test Workbench, Impact Analysis, Business Process Monitoring, etc. This document will give some examples on how to construct your project and discuss how your project will evolve during the project lifecycle.
Project Administration Concept
Storing project documentation in a central location is not a new concept. There are several options available to SAP Customers today – we can store documents on a file share, in SharePoint, Documenum eRoom or any other number of third party document storage software solutions. The key differentiator with Solution Manager Project Administration is that documents can be linked with other key project information. We can associate a document like Technical Specifications with the actual custom development in the development system, we can assign a developer, we can link it to a business process and we can associate that document with the end user training documentation or security role needed to run it. This is where other solutions fall short and Solution Manager delivers. While some may argue Solution Manager is not the easiest tool to use and adoption rates amongst project teams is slow. It is still the best tool available for running a transparent SAP implementation or upgrade project.
This blog is not meant to be the sole source you’ll need when implementing Project Administration. It is meant to guide the reader in choosing a structure to start a project and then explain how the project structure can change later. Some of the questions this blog will answer include:
What are other customers doing?
How can we organize the project so it’s easiest for project team members?
What’s the benefit of creating nodes specific to custom development?
Constructing a Business Blueprint
Transaction Code SOLAR01
The primary purpose of this transaction is to create a project structure which defines the business processes that you want to implement or upgrade in the system. The project is subdivided into Business Scenarios, Business Processes and Business Process Steps. For example:
- Business Scenario: Finance
- Business Process: Accounts Payable
- Business Process Step: Receive Invoice
In the following sections we will discuss some of the approaches available to us and their advantages/disadvantages.
Project Team Approach
Using this approach – we structure our project very similar to how we structure our project team during the implementation or upgrade. Very often, teams are structured by core module and then by function which lends itself well to our capabilities in Project Administration. For example a project team structure below would enable us to create a project where people can easily find/update information.
Project Team
Project Structure in Solution Manager
Project Team Approach Example
Explanations
In the above example, we would create a project structure in Solution Manager using the project organization chart as a guide. Some considerations...
- We only have three levels to work with in Project Administration and lowest level should be the business process step – i.e. the transaction, program, interface or manual process that will be executed.
- The development team gets their own area to store information regarding their WRICEF objects. Why not store each development within a business process? When first identifying what needs to be developed – we’re not always sure where the development resides in the business process. Storing all functional/technical specs, design docs, workshop output under Development Objects enables our technical team members to quickly access information. Later in the project lifecycle – we can use the Copy > Link functionality to provide links in the business process where we have custom objects.
- What would Basis and Security teams store in Solution Manager? We should be storing all of the sizing inputs, client strategies, role matrixes, design documents, etc. A successful implementation of Project Administration depends on all team members storing all project related content in one place.\
Business Process Approach
In recent years some organizations have moved to a more end to end business process approach rather than the module specific approach described above. This idea has gained traction since it establishes owners for the entire business process, allows our project team member to become more cross functional, and more closely matches how we would want to monitor a business process when in production. Some examples would include – order to cash, procure to pay, build to ship., hire to fire (for lack of better word), etc.
The difficulty in using the above approach is that it changes the way we view and run a project. Additionally, it requires a good sense of what the business process will look like in the new system. Sometimes we don’t have the entire picture of the process until the completion of the first integration test or mock cutover. Project Administration does maintain the functionality for us to move objects within the node construct as needed and as the business process evolves throughout the project. Here’s an example Project Administration node construct based on the business process approach. (Disclaimer: I’m a Basis person by trade – these examples may not be actual business process steps but are used for demonstration purposes)
Project Structure in Solution Manager
Business Process Approach Example
Explanations
In the above example, we achieve our goal of being able to view business processes from end to end. This can help us find gaps or inefficiencies in the business process – and can also be an opportunity to help us standardize our business processes. However, this structure can increase the learning curve when your project team first gets started using Project Administration. Most project resources today have a very module specific mindset. Some key points
- The business process approach in Project Administration sets us up for a quick migration to business process monitoring and impact analysis (understand impact of patches on a business process). The additional up front work will pay off later.
- We still give Project Management, Basis, Security, and Development their own folders to store their documentation. For Development related documentation – we keep nodes for each object or group objects – then link back to the business process.
Summary
Project Administration is a robust, stable, tool to aid in the implementation, upgrade or support of your SAP solutions. Solution Manager is now the core to the operation of an SAP landscape so it is also the logical location for all project related documentation. Project Administration does require some up front effort to train the project team and some ongoing governance to ensure the tool is being used as it was designed. However, the long term benefits out weigh the initial cost of effort. Once your solution has been documented in Project Administration, you’ll be able to move onto more advanced tools like:
- Impact Analysis – know what business processes will be potentially affected by a patch form SAP
- Business Process Monitoring – Monitor common business processes within a single system or across systems
- Change Request Management – Manage change to configuration and applications more efficiently and by business process.
As stated in the beginning of this blog – this was not meant to be the end-all guide for Project Administration. However, I do believe it has provided you enough information to begin to best leverage the many features of Project Administration.
5 Comments
