A thought on interoperability between project management and technical management tools in SAP projects
Jira or Azure DevOps are very popular and frequently used to support and manage projects. In the SAP project environment, this is often supplemented with Change Request Management (ChaRM) in SAP Solution Manager. When this comes together in SAP S/4HANA transformations, for example, the existing gap and lack of standard integration between the various tools becomes apparent.
On the one hand in Jira/DevOps with the requirements or user stories that are to be implemented accordingly in the project. On the other hand, with ChaRM, which provides the procedural and technical support for structured and well-managed SAP Transport Management. The connectivity between the two tools is the key to transparent and error-free management and implementation within the project.
We often see projects where the project-supporting tools have been defined at the beginning. We see deficits for the project itself with regard to the extensive process-related characteristics and necessary integration of the tools with each other in order to utilize and achieve maximum added value. These should be solved.
It is recognized very late that the process break from user story to technical implementation and the management of transports can be harmful. A missing link between user story and change very quickly leads to a lack of clarity regarding the status of the implementation and, at the latest, to a lack of transparency during transport to subsequent systems. In extreme cases, complex manual synchronization between the tools must be carried out to ensure smooth transport to the subsequent systems and secure operation. With large releases, this can be very time-consuming and error-prone. Here, just as with the classic business processes, it is important to keep an eye on the E2E process and ensure that it runs smoothly. Seamless integration therefore also helps with release management and the overall control of the respective implementation. Regardless of the number of tools and help in the process itself, the expectation in most cases is that the management, including status, reporting and overview, as well as the linking to the other tools, can be tracked in a central tool for everyone.
Recommended by LinkedIn
It is therefore important to determine and define the strategy regarding support processes and tools for the project at the start of the project. The later this is done, the more complicated it becomes and, in most cases, the more time and effort is required for adjustment.
The positive thing is that there are already a number of products and solutions for this type of integration that overcome these challenges and offer suitable integrations. Which one is right for you depends on your individual needs and requirements.
We help to close this gap and identify and implement the right integration for the specific requirements and defined processes. We have strong partners at our side with whom this can be implemented smoothly and quickly.
Hi Alexander Barth, thanks for the interesting article! Could you give a hint at some of the products and solutions which are available for the integration? Furthermore, what is your take on Focused Build in this context? Since it is another module of the SAP SolMan, you would expect a better integration, right? However, what about the features and usability? In one project, we are currently introducing Azure DevOps as an alternative to Focused Build and implementing an interface to sync these two tools... Looking forward to more insights from you! Kind regards, Daniel
Hi Alex. You precisely describe the situation I found in many projects over the last years. Regarding transparency I´d like add that it´s an issue for the auditors as well if there is no accurate linkage between the business requirement and the acutal deployments that went into the production system (audit trail).