Starting point
As an ALM consultant, you are often asked by customers and colleagues what approach or SAP tool they should use for an implementation project. The usual consultant answer ‘it depends’ will usually be justified this time, especially if it is not a ‘simple, small project’ in which the company ‘only’ wants to implement a cloud application without major customizations trust-based with a small team, for example.
Bigger SAP transformation projects require a well thought-out toolchain in order to efficiently organize the implementation and operation of SAP solutions and the entire landscape. SAP offers mature and proven methods and toolchains for this. However, customers usually also have their own requirements, tools and specifications that are (or should be) used for all projects throughout the company. Many companies and project members have wishes, experiences and preferences, but also dislikes from former projects that need to be taken into account. ‘SAP people’ like to rely on SAP Solution Manager and non-SAP people prefer tools like Jira, Confluence & Co. Often, of course, it's also different. 🙂
Finding a suitable toolchain that is accepted and used by everyone is often not that easy and there are many ways to find the right toolchain.
Solution Manager Focused Build or Cloud ALM
The fact that SAP currently offers two generations of its ALM solution does not make the choice any easier. SAP Solution Manager and SAP Cloud ALM basically pursue the same goals, the application lifecycle management of the solutions used in the company but offer different approaches and functionalities.
SAP Focused Build has been specially developed for agile projects within the SAP landscape. It provides tools for planning, executing and monitoring projects and enables seamless integration, making it easier to manage requirements, tests and changes. It has been around for years, works (mostly), but is soon to be replaced. The ready-to-run Add-On is part of the maintenance contract and can be used indefinitely without license costs. The end of maintenance for Solution Manager has been announced for 2027, extended maintenance will continue until 2030.
SAP Cloud ALM (Application Lifecycle Management) is the new modern and cool cloud-based solution (SaaS) from SAP that helps companies manage the entire lifecycle of their applications. It is developed from scratch, is undergoing agile further development and is currently being heavily promoted. SAP provides the necessary hardware, infrastructure and technical installation. Only in exceptional cases of extended use of SAP Cloud ALM do customers have to subscribe to additional storage.
There are plenty of comparisons between SAP Cloud ALM and SAP Solution Manager (with or without SAP Focused Build). To summaries, almost everyone will agree that SAP Cloud ALM, especially for Implementation, could still be in need of development in some areas, especially when it comes to larger and more complex implementation projects.
Solman Focused Build (FB), on the other hand, works well for more complex projects and is tried and tested. It has everything you need but is soon out of maintenance and often not so popular with users.
Many customers already have experience with the SAP Solution Manager Focused Build. This has mostly worked quite well but has not necessarily been fun. It is difficult to say whether this is due to a ‘lame’ Solution Manager that is often rather neglected in terms of administration, the rather complicated and cumbersome standard FB workflows or a general rejection of even more tasks and projects. It's probably all of the above. However, customers with focused build experience in particular are currently being advised to use the tool until Cloud ALM has the necessary functionalities. The roadmap of when which functionalities might be available offers a good overview, but not real planning security.
Existing or planned tools in the company
Most companies will already have existing tools that have been introduced and are used throughout the organization. For non-SAP applications, departments and teams in particular, the willingness to familiarize themselves with and work with ‘complicated’ SAP and/or FB workflows in parallel to their normal tools will understandably be rather low. In a transformation project, the ‘non-SAP part’ is naturally often underestimated when ‘SAP glasses’ are on.
The project will quickly agree on a few ‘new’ SAP tools, SAP Signavio to model its processes and possibly SAP LeanIx to document and manage the application landscape.
If a company already uses tools such as Atlassian products, there will often be a desire to continue using them. For example, Confluence as a documentation, knowledge base and collaboration platform for creating and sharing content. All (technical) documents can generally be written and stored here. Jira, to manage projects, create requirements, create, track and trace tasks, bugs handling and service desk...
Depending on usage, additional license costs may be incurred.
However, it will hardly work without SAP Solution Manager or SAP Cloud ALM (see roadmap), as they offer comprehensive application lifecycle management, sophisticated transport management for SAP and non-SAP landscapes, release management, functioning, harmonized workflows and integrated test management also have many advantages, none of which can be easily replaced with other tools.
Options for an integrated toolchain
A compromise here can be a combination of ‘both’ worlds. Jira as a tool for recording, planning and monitoring all activities, SAP Solution Manager with (oder even without) SAP Focused Build as the tool for the implementation. SAP Cloud ALM can be used for small ‘lighthouse projects’ or operations etc.
You can build the interfaces between Jira and SAP yourself or look for a ready-made solution and select and customize it according to your own wishes and requirements. What is then ultimately mapped and synchronized, how and where, what the leading system is in each case, how many interfaces there are and what the entire workflow ultimately looks like should be defined and ‘decided’ at a very early stage in order to be able to coordinate and decide on the project governance. Getting everything up and running, the implementation, creation of documentation and training then take a little more time than if you use ‘turnkey’ tools and workflows.
The teams and project staff can then work mainly in Jira, record their projects, requirements, tasks and to-do's there and plan and monitor the implementations.
Depending on the workflow, all or only the ‘SAP tasks’ (as requirements/work packages and work items) could then be synchronized and processed in the SAP Solution Manager, for example. The non-SAP tasks could remain in Jira, which will then be the leading system for all activities, or everything is pushed to SAP. Some very well thought-out solutions and additional functionalities are already offered here, but these can always be customized. Some interfaces are based on SAP, others on Jira, here it should be ensured that the cooperation of the teams and also responsibilities are well coordinated.
SAP Test Steps can be used as the testing tool in order to utilize the advantages of integration into the SAP workflow. Other tools can certainly also be used here, especially if they are already used and recognized in the company. In general, however, the SAP Test Steps are highly recommended in terms of user-friendliness and the possibility of connecting automation tools and Ki support for test case creation. (SAP Test Manager glasses 🙂 ).
If you want to use SAP Signavio for process modelling, the Business Process Model Connector for SAP Signavio Solutions can be used to transfer the processes and process steps to the solution documentation in Solution Manager. This saves everyone the tedious work in the SAP Solution Documentation but can also lead to new problems.
At a later stage after the transformation to Cloud ALM, Jira (if needed) and SAP Signavio can be easily connected to SAP Cloud. However, this should probably only be done after the end of the project, not to make life even more difficult for yourself.
If you use SAP Signavio, you should ask yourself at an early stage how to define, structure and model your processes in a meaningful way so that they can be mapped and managed clearly and sensibly in SAP Solution Manager and possibly SAP Cloud ALM. There is certainly still potential here to bring the two ‘worlds’ together.
In SAP with (or without) Focused Build projects, all documents etc. are stored in the SAP Solution Documentation, but if you prefer to do this in a tool such as Confluence, which is generally used for all documentation in the company, you can adapt the FB workflow accordingly and either upload the documentation, only link it or not reference it at all.
Other tools such as Microsoft or Google products will probably also be used for all toolchains.
Here and with the entire integrated toolchain in general, you need to look at what compliance requirements exist (or could exist in the future) and ensure that you can fulfil and cover them. The advantage of the SAP Solution Manager with Focused Build should be mentioned here, as it can cover pretty much everything.
Conclusion
Even though SAP Solution Manager with SAP Focused Build offers a turnkey solution and many advantages for implementation projects, especially in the context of SAP S/4Hana, and the new modern ALM platform is already available with SAP Cloud ALM, there are certainly many reasons and opportunities to adapt and expand the toolchain. With advantages such as better usability and acceptance in the company, but also some (many) risks (if errors occur, it's always the other person's fault), higher costs and expenses (for additional tools, licences), etc. A customized toolchain will always require more effort and coordination, but it certainly has its advantages if it suits the project and company better.
Each project has to make its own decision; switching to a different workflow or other tools or even cloud ALM during the project will be rather difficult to realize. However, you may also come to the conclusion that the advantages of a complete turnkey solution are not to be sneezed at. So, the usual and never wrong consultant answer remains “it depends, but we can talk about it."
