Maintenance with SAP Cloud ALM
In this blog post I’d like to share some insights on how SAP Cloud ALM can support your maintenance activities. It is divided into following chapters:
- Project creation and deployment plan assignment
- Utilizing process scoping to structure the project
- User story and feature handling for maintenance activities
- Deployment and testing activities
Project creation and deployment plan assignment
Creating a Maintenance project is the starting point in the Projects and Setup app. For a maintenance project it is not necessary to select an SAP Activate task template and the phase can be set to “Run” directly.
Create your sprint plan in the Timeboxes area to organize your maintenance work within your project.
I would always recommend creating a deployment plan combined with the corresponding system groups. Within the deployment plan create your releases according to your delivery time windows to production.
The deployment plan can be utilized to plan the feature delivery to production accordingly. If you want to plan your agile development based on sprints it is useful to align the sprint schedule with the release schedule. This leads to the separation of the implementation planning and the deployment planning hence you are very flexible. In this example I chose bi-weekly deliveries to production.
The system group for the maintenance landscape can be created in the System Groups tab. If you want to learn more check out the “What is a System Group” section in the SAP Cloud ALM for Implementation Expert Portal.
The deployment plan must be assigned to the maintenance project since it can serve several projects in parallel.
Depending on your organization it can make sense to create teams for different business areas or LoBs. This will help you in assigning work items to the right group of project team members responsible for a certain area.
Utilizing process scoping to structure the project
Create the different scopes for the maintenance project based on the business areas or E2E processes. Examples could be Finance and Sales or P2P and O2C. This should fit to your teams you defined during project creation.
Select the solution processes for the different scopes to easily connect the maintenance tasks to the respective process. This helps you identify the maintenance load per area easily.
User story and feature handling for maintenance activities
Those user stories can be estimated, planned, and assigned to the respective team or developer. Based on the defined sprints you can do your sprint planning properly. With the requested release an intended delivery date can be added accordingly.
Features can be created on demand for the user stories which should be deployed to production per deployment window e.g., for bi-weekly deliveries. Here it is recommended to look at your release plan for the maintenance.
Here it is important to assign the appropriate release so that you can figure out which features are dedicated for which deployment window to production.
Several user stories relevant for the maintenance of your production systems can be assigned to one feature. Example: Two developers working on different user stories, but the changes shall be deployed to production together. In this case it is advised to assign both user stories to one feature. You must switch to Edit mode to assign user stories to a feature.
Deployment and testing activities
This ensures that both parties working on the user stories assign their transports to the same feature. When the user stories are done all corresponding transports should be in status Released and assigned to the feature. To assign a transport switch to Edit mode and click Assign in the transport section.
Keep in mind: Features can contain transports for different SAP Solutions e.g., SAP S/4HANA Cloud, private edition, and SAP Integration Suite – Cloud Integration transports. By this hybrid use cases are covered already.
Test Cases can be assigned to the user stories and as soon as the deployment of the features has been triggered to the test system the acceptance test can be done.
Triggering the deployment to the test systems can be done in status In Implementation of the feature.
Via the “Handover to Test” button you can switch the feature to status In Testing.
Navigate to test case assigned of the respective user story and execute the test case.
Hint: After the successful test execution, I would recommend storing a screenshot of the positive test result within the user story or the feature.
In the feature overview you can filter for the status Ready for Production and the upcoming delivery to select the features to be deployed to production.
Nice to know: Before deploying to production, you can download the list of involved ABAP transports to use the Transport Request Check Tool (program: /SDF/CMO_TR_CHECK) to execute some transport related checks.
Now you can check per feature if the deployment to production went fine.
Nice to know: In case one or several transport(s) failed in production you can use the same feature to assign a new transport to correct the error situation. The failed transport can be set to “Repaired” manually in the feature.
In this blog post you’ve learned one way how to utilize SAP Cloud ALM for your maintenance activities. There are additional functionalities like tag management and traceability apps which can contribute to a successful maintenance project.
Looking forward to receiving feedback. For latest updates and notifications, you can follow me by clicking Moritz Gysler.
Thanks Moritz Gysler for the description and ideas how to use SAP Cloud ALM for maintenance.
It goes in the right direction 🙂
Great Blogpost and ideas Moritz Gysler
Could you check internally if it makes sense to establish an additional status on the user story level as well? I think it would be good if we also had a status there where we could see that the business department has to test something and also that the test is confirmed by the business department. Perhaps we could do something similar to requirements with the approval: We define whether a test approval is required for the user story or not. What does Jagmohan Singh Chawla and the community think?
Thanks for the feedback. We will discuss this point internally. It makes a lot of sense to have options to decide which entity is the one to be tested.
Thanks Moritz for detailed information about Features.
One question, can we create new transport from Feature?
Also, can you define relation/similarity between User story & Feature with RFC & Change Documents of ChaRM in SolMan. This way we can better relate and understand.
Thanks a lot for your feedback.
Creating ABAP transports from features will be delivered with one of our next SAP Cloud ALM feature deliveries.
In general I would see a requirement in SAP Cloud ALM as RFC. But in the described scenario a user story can be seen as the RFC and the feature as the change document. I would always recommend to utilize features to document changes affecting production instances.
Hope that helps.