Example - SAP Change Workflow in Zendesk

Generic workflow

Let us show you an actual example of how you may be using our SAP Transport Management for Zendesk app.

As a company, we generally use 3 different change workflows for SAP:

• Standard Change: used to perform low-risk changes that are uncritical and frequently used and can therefore be processed without approval;
• Normal Change: used to perform the implementation of a request for change (new functionality, new feature in existing functionality, or corrective activity for a minor defect in existing functionality);
• Urgent Change: used for fast implementation, for example, if you want to fix an error in existing functionality and should be transported to Production faster than a normal change.

Here is how our Normal Change workflow looks like in Zendesk - both the Change Type and Change Status options are included in the application:

1. Created: A Request for Change has been approved and the Agile Team is creating a Normal Change that can be assigned to the responsible Development team.
   
   
2. In Development: One or multiple developers are assigned to the change, they create Transport requests in DEV and start the work - once done, they release the tasks and set the change to the next status.
   
   
3. To Be Tested: Basis team creates and imports Transport of copy into QA, then one or multiple testers are assigned and perform the required testing - if rework is necessary, the change document goes to "In Development", otherwise it moves to "Successfully Tested".
   
   
4. Successfully Tested: Basis team imports the "real" transports into QA (and Preproduction) and sets the change status to "Authorized for Production".
   
   
5. Authorized for Production: Based on the release calendar, the Change Document remains in the status for as long as necessary before eventually getting imported into Production.
   
   
6. Imported into Production: Transports are in production but ITIL best practices recommend to have a last check before definitely closing the change document.
   
   
7. Confirmed: Final status, the document is closed and archived.
   
   

Zendesk + SAP

Now, there is nothing wrong with this workflow (although this is just a basic example that would have to be adapted depending on your internal processes and the number of managed systems). However you don't really have any connection between the change document and what is really happening into your system.

You may want to setup some custom fields, etc. but this is far from ideal because 1) you are prone to human errors (people forgetting stuff?); 2) you are working in silos, not everyone has access to the information at the same time; 3) you are not exactly bulletproof when the time of the audit comes.

The SAP Transport Management for Zendesk app has one purpose: making sure whatever belongs to the Change document itself remains in Zendesk, while the SAP activities themselves are still managed directly in SAP. For example, the creation of the transport itself should always be triggered by a change in the document status (from "Created" to "In Development"). This is to ensure maximum traceability and transparency by giving the information to anyone involved at the same time.

Capabilities overview

Here is an overview of what the application can do (some confidential onscreen information has been blurred):

1. Create a Transport Request in the SAP system

2. Remove from the transports list and/or Delete the transport in the SAP system

3. Retrieve and/or Update transport information in the SAP system

4. Create a Transport of Copies from a transport linked to the Zendesk change

5. Release a transport from Zendesk when all tasks have been released in SAP

If you have other requirements in mind, please share them with our support team!