This blog describes another use case which became relevant in my discussions with the DSAG (German SAP User Group) when Requirements Management was built. Additionally, I describe in this blog how to customize this use cases in standard SAP Solution Manager 7.2 Requirements Management for a copied customer transaction type.

Transfer Requirement to Request for Change

Let’s assume a Business Requirement was created by the line of business (LoB).

It was approved by the business manager to be evaluated by the IT department.

As a result, the Business Requirement has reached the status Handed Over to IT and the IT Requirement has been created.

The responsible solution architect who works for the innovation group evaluates the requirement and finds out that it is fairly small and appears easy to implement with an estimated 3 men-days of work. Also, it is not an entirely new requirement but rather a round-off, more like a bug-fix requirement.

He discusses this with his requirements manager and they decide that the requirement can already be handled by the development group, which usually does the maintenance. From ITIL perspective this means that it should be implemented by a request for change belonging to the maintenance group.

Therefore, it would be most practical to have a functionality that creates a request for change from the IT Requirement. The request for change should be a follow-up document of the Business Requirement. That would allow the IT Requirement to be closed and the maintenance group to work on the request for change.

In the following section, you learn how to customize the functionality of setting the IT Requirement to the status Transferred to RfC and creating a new IT Requirement, which is assigned to the Business Requirement as a follow-up document. The screenshots display a ZMIR created from a ZMBR.

There are several parts to be customized:

1. Implement a prerequisite note.
2. Create the new status and authorization key for Transfer to Request for Change in the status profile.
3. Adopt the status of the Business Requirement.
4. Create the PPF action and conditions to set the status.
5. Create the PPF action and condition to create the request for change.
6. Adopt the Schedule condition to set the status Completed.
7. Change Request Management Framework Customizing
   1. Define status attributes.
   2. Actions
   3. Consistency checks
   4. Predecessor status
   5. Successor status
   6. Copy control
8. ITPPM integration (optional)
   1. Map task status to transaction status.
9. Update roles.

Implement Prerequisite Note

SAP Note 2368697 has been implemented for ST 7.20, SPS 02-03 in order for the PPF action implementation HF_REPLACE to work.

Create the new status and authorization key for Transfer to Request for Change. Go to Customizing activity Define Status Profile for User Status and select your copied ‘ZMIRHEAD’.

First create the authorization keys for the new status by selecting Authorization key.

The maintained status is Transferred to Project (here E0009).

Create the PPF action and conditions to set the status Transferred to RfC.

Create the PPF action by copying it from another PPF action, which sets a user status, for example, _CLOSED.

The PPF action is here named ZMIR_TRANSFER_TO_RFC.

Apply the Customizing as displayed below.

The PPF action should have a PPF action container element ‘USER_STATUS’ with value ‘E0009’.

Add the PPF schedule condition for this action similar to the following:

Create the PPF action to create the Request for Change document and add it as follow-up document to the Business Requirement

Create the PPF action by copying it from the PPF action _SET_KB_DELTA. The PPF action here is named ZMIR_CREATE_REASSIGN_PROCTYPE.

Apply the Customizing as displayed below.

The PPF action should be customized to run only once successfully.

The PPF action should have a PPF action container element ‘TARGET_PROC_TYPE’ with value ‘ZMCR’ (your customer request for change).

Add the PPF schedule condition for this action similar to the following:

Add the PPF start condition for this action as follows:

Adopt the Schedule condition to set the status Completed.

The PPF action _CLOSED has to be changed so the Completed status can as well be set from the status Transferred to RfC.

Change Request Management Framework Customizing

There are several Customizing activities to be done in the Change Request Management Framework settings.

Define status attributes.

Make the new status known to the framework.

Change Request Management Actions

Only if you use ITPPM integration, the Change Request Management action for the new user status to set the ITPPM task status is needed.

Define that the actions are executed as late actions.

Define Change Request Management consistency checks.

They check that the task status is editable before it is set.

Predecessor Status

Request for change reaches the status Implemented and sets the Business Requirement to status Implemented.

Request for change reaches the status Rejected and sets the Business Requirement to status Rejected by IT.

Copy Control Customizing

We need copy control Customizing for creating a request for change as a follow-up document from an IT Requirement.

CRM Copy Control Customizing

Change Request Management Copy Control Customizing

Copy Customizing for Texts

This depending Customizing defines which texts should be copied. You might add further texts to the description text.

Copy Customizing for Dates

This depending Customizing defines which dates should be copied. You might add further dates to the implementation date.

You can access the second part of the blog here.

ITPPM Integration (Optional)

Only relevant if you are using ITPPM for project planning.

Map Task Status to Transaction Status

The following defines which task status you should set when the IT Requirement reaches the new status.

Role Update

Be aware that the authorizations might not be complete. Therefore, ensure to check what needs to be adapted that if you use changed standard roles. This can be solved via the authorization trace.

The solution architect needs the authorization to create a request for change and set the status Created including:

• CRM_ORD_PR with activity ’01’ and ’02’
• B_USERSTAT with BERSL = ‘SMCR_00′, ACTVT = ’01’, OBTYP = ‘ ‘, ‘COH’, ‘COI’ and STSMA = ‘HEAD’

If you want the solution architect to be able to change some fields in the request for change, for example, the change cycle assignment, etc., you have to add the respective SM_FIELD authorizations.The change manager needs authorization to set the Business Requirement status Rejected by IT,  Implemented, Handed Over to IT:

• B_USERSTAT with BERSL = ‘SMBR_04’, ‘SMBR_11′ and SMBR_08′, ACTVT = ’01’, OBTYP = ‘ ‘,

‘COH’, ‘COI’ and  STSMA = ‘HEAD’

The business manager needs authorization to set the request for change to Validation:

• B_USERSTAT with BERSL = ‘SMCR_09′, ACTVT = ’01’, OBTYP = ‘ ‘, ‘COH’, ‘COI’ and STSMA = ‘HEAD’

What You Get

In the IT Requirement, you are now able to transfer the requirement to a request for change by choosing the action Transfer to Request for Change.

After the document was saved, the Business Requirement has a request for change as follow-up document.

The IT Requirement can now be completed.

At the Business Requirement, the request for change will set the status Implemented when it reaches the status Implemented.

If the request for change reaches the status Rejected, it will set the Business Requirement to status Rejected by IT.

Be careful with setting the Request for Change to Rejected as it is a final status. Afterwards, the Business Requirement should be set to Rejected as well. The use case to recheck the Business Requirement and create another follow-up document is not covered here as the follow-up IT Requirement is created only once if the Handed Over to IT status is reached.
Therefore, you would run into a dead end here.

Further enhancements are needed to solve this. This would imply development and customizing. Examples are PPF actions to create an IT Requirement or a Request for Change manually with status Handed Over to IT in case we do have all follow-up documents with a final status.
This can be accomplished by using PPF action implementation AIC_COPY_DOCUMENT.
Check out PPF action SMBR_CREATE_IT_REQUIREMENT for further details on PFF implementation.
The scheduling condition of the PPF action should check on the user status Handed Over to IT.

The starting condition of the PPF actions would need a BadI implemention of BadI definition CONTAINER_PPF. This sets a specific value in a customized PPF condition parameter in the PPF schedule condition provided there are only follow-up documents (IT Requirement and Request for Change) with a final status. The condition then checks if this container value is true and schedules the PPF action for this case to be ready for execution.

Check out PPF action SMIR_WAITING_FOR_EXECUTION, which is only avaiable when the IT Requirement does not have a Business Requirement as a predecessor document. This is the case in the IT Requirement stand-alone scenario.
This PPF action uses BadI implementation AIC_NO_BR to check if there is no Business Requirement. If so, it sets the parameter NO_BR in the PPF action condition to true.

The parameter is checked in the PPF schedule condition.

I have customized and tested this scenario in our internal system, so it should work. Nevertheless, if you find an error, please contact me.
Enjoy,
Michael