In my previous post I discussed some of the functionality available in Solution Manager (SOLMAN) to capture and build business process scenarios, processes and steps.  Once you captured this information it could be readily transformed into a test plan and SOLMAN functionality used to execute, manage and monitor testing.

This is good functionality and once your business scenarios, processes and steps are in SOLMAN you can use them as a baseline for additional projects.

Consider the “global template” scenario that crops up in companies today: a core set of business processes are designed and rolled out on a global basis – the only deviations allowed are those mandated by local legal requirements (a.k.a. localization).  On top of this there are the business scenarios that fall outside of the business template.  You don’t want to build a standard implementation project from scratch each time for the core business processes.  This is where template projects save you time and effort.

SOLMAN Templates and Business Process Templates

Using SOLMAN and template projects you can capture that global template with its common business scenarios and then extend it for local variations and non-standardized business scenarios.  Let’s work through an example.

Template Project Definition (SOLAR_PROJECT_ADMIN)

Consider a template project (ZTPC300) with some business scenarios defined in the template as shown below.  In this template I initially defined three templates: one for order-to-cash (OTC), one for procure-to-pay (P2P), and one for financial processes (FIN).  From a global business template perspective let’s assume that there are common processes in OTC, P2P and FIN that need to be rolled out in each country (or business unit or division or legal entity… you choose).

Having created these templates in the project administration I go over to project maintenance with transaction SOLAR01.

SOLMAN Project Maintenance (SOLAR01)

Now, in this transaction you can see where business scenarios have been assigned to the templates from the project definition.  In this example the OTC transactional scenarios and the OTC master data scenarios have both been assigned to template ZTPC_TEMP001.

As discussed in my previous post there is further detail at the business process and step level within the SOLMAN project.  This is where I would expect to find detailed descriptions of transaction execution, business rules, etc.

Implementation Projects & Template Projects

At this point you might be wondering what the point is of this set up.  Having invested the time identifying the content of my template project that constitutes my global business template I can use it when I want to build a new implementation project for the next part of my global roll out.

Now when I go to transaction SOLAR_PROJECT_ADMIN and create a new implementation project I see a curious thing under the SCOPE tab in the project definition (see below).

The three template areas from my template project are made available to me and, if I want to, I can further select at the business scenario level to include or exclude the transactional and master data scenarios.  In this case I have selected transactional scenarios only.

If I now save my project and view it with SOLAR01 I see a project that includes the transactional components of the template project along with the lower level details.

This means I don’t have to build out all this content because it was brought in for me from the template.  Pretty neat.

One Implementation Project from Many Templates

In one of the graphics earlier you may have noticed that the templates available to me when I was building my new implementation project included the OTC, P2P and FIN components but there were two other components available: Z_EMS_001 and Z_SDSO_001.  How did that happen?

One of the neat features about building an implementation project is that you can pull in components from multiple templates.  In this example, I have two template projects with available components which means I can select from both template projects to build my implementation project.

This could be useful if, for example, you had templates for historical reasons for common financial processes, common HR processes, common procurement processes and you wanted to roll these out together in one project for a new business unit.  The SOLMAN functionality allows you to pull the required template components from the three source projects and combine them into one implementation project.

Hints & Tips

If you want to start using template projects getting the sequence of events and status changes in the right order will save some frustration, so here’s what I recommend:

• Create the template project with SOLAR_PROJECT_ADMIN
• Build out the project structure with SOLAR01
• Identify the nodes on the project you want to use as template components
• Create the template components with SOLAR_PROJECT_ADMIN and leave them in private status
• Update the project nodes using SOLAR01 with the appropriate template component.  If the template components are in a public status this step is not possible
• Use SOLAR_PROJECT_ADMIN to change the template component status from private to public.  This makes the component available when you build a new project.

Summary

This method in SOLMAN to build implementation projects from template projects is a terrific time saver.  It allows you to re-use and update project artifacts giving you a jump start on value adding activities that should bring value to your business.