Managing SAP Changes with ServiceNow

[Tony K]

This article is going to focus on using ServiceNow to manage the SAP Change Transport process through multiple instances. Overall the process is fairly simple and straight forward but I’ll elaborate more in the hopes that this helps someone out. We really didn’t find anyone else who was doing the same thing in ServiceNow. In addition the one or two vendors that offer SAP Change tracking were expensive and we’re not mature enough to justify the cost.

 When we deployed ServiceNow the initial goal was to only manage SAP Transports to PRD. To make using this process easier, a Change Template was created that automatically inserts the Change and Change Task right away. The caveat here is that in order to get this type of template to work correctly and insert a Change Task right away, you have to create a new module for the template on the left navigator. The Change Task is needed to notify the Basis team that they can proceed to move the transports after the Change is approved in CAB. In addition the notification that goes to the Change Task assignment group on insert was changed to not send until the Change Request is approved.

 The PRD process consists of two approvals. First a technical approval occurs. This is automated using the managed by field from the business service table. Once this approval passes, then the manager of the Assigned To user gets an approval request. This makes sense for us because the Assigned To person is performing the change. After this second approval, then the Change Request goes to our weekly CAB review.

 Recently the addition of managing SAP Transports to QA was added. This is similar in that a second Change Template was created for the QA transports. This process was updated in that there is only 1 approval that goes to the SAP Team managers. Once they all approve, then a notification is sent to all team members that work under SAP. As mentioned before, the email notification for the Change Task assignment group is only sent once the Change Request gets approved.

 The process itself is fairly simple. For example sake, an incident needs a SAP Transport to resolve. The SAP analyst can go create a Change using the SAP QA template. From here they add the INC number into the parent field on the Change. In addition the Change record has related list for Incidents Pending Change so multiple incidents could be associated. From the Incident there is a field called Change Request to link a Change as well. After the change is created, risk assessment submitted, then approvals go out and follow the normal process. If testing fails or additional modifications are needed, the analyst clicks copy on the most recent QA change, checks a box to indicate this is a SAP QA change, the correct workflow is associated and then a new change is created. The second Change gets the parent field populated with the previous Change. This could go on for a few iterations and each new copied Change is associated with the Change before it, creating a whole chain for tracking purposes. When the Analyst is ready to move to Production, they copy the most recent QA Change, update the Short Description to start with PRD, leave the QA Change checkbox unchecked and then and carry on like normal.

 A few fields were added to the Change Request form in order to get this to work. A field to track the SAP Transport numbers was necessary. In addition another checkbox field was added to indicated if the Change was for a Transport to QA or Transport to PRD. As Changes can be copied over and over, the checkbox was the method of telling ServiceNow which type of Change it was and which workflow to use. The copy change UI action was also modified to copy certain fields over. Related lists were added on the Incident to associate changes and on the Change form to associate multiple Incidents if needed.

 Hopefully these steps help someone else who is looking to keep tabs on SAP related changes in ServiceNow.