Requirements management with SolMan 7.2
Many companies that use SolMan for their ITSM processes have sorely missed an input channel for requirements from the business department. Today, requirements are still collected, evaluated and passed on to the IT department in cumbersome and lengthy processes.
It is not uncommon for requirements to simply be sent to the responsible person via e-mail. Paper forms are also still a common medium for formulating and describing a requirement. These then travel through countless desks and committees until all the necessary approvals have been collected and everyone involved has been informed.
In the best case, requirements are managed in self-built tools and then transferred manually or via interfaces as change requests in Solution Manager. The requesters then often receive feedback on the current status of the development only via organizational channels.
This can now change, as SolMan 7.2 offers a fully integrated process for requirements management. This is intended to cover the complete life cycle of the requirement from capture to realization and productive implementation.
The delivery includes two new transaction types: the business request and the IT request. Both are CRM documents and offer the complete functions analogous to Change Control Management.
In the business requirement, the department can describe its request, prioritize it according to urgency and impact, categorize it, specify the desired implementation date, and pass it on to the requirements manager or department head for evaluation.
Important information should be provided at the time of recording, e.g. benefits, cost savings, reasons (e.g. legal determination), business case, processes and groups of people affected, etc.
The requester can use the multi-level categorization for this purpose. Additional categorization options may be required that are not provided in the standard system. These categorizations could, for example, be mapped using customer-specific fields.
Nevertheless, the requirement is documented in SolMan right from the start. The solution documentation assignment block is already included in the business requirement, so that a reference to the affected business process can be stored directly. In the same way, existing documentation such as user stories or even test case drafts can be stored.
The workflow of the business requirement provides for an evaluation phase, after which the requirement is handed over to the IT department. The interaction between the two documents is exciting.
Content is transferred in full from the business requirement to the IT requirement. However, what offers significant added value is the feedback of the progress in the processing of the requirement towards the business department.
This is done by automatically implementing the user status of the business requirement, depending on the current status of the IT requirement. The business department is constantly involved and can also help control the implementation of the requirement.
The IT request basically behaves like a change request. However, there is one significant difference to mention here. There is no possibility to extend the scope. Thus, only change documents that have been initially defined in scope can also be set to productive.
So why do you need an IT requirement when a change request can already perform the same tasks? The obvious answer at this point is to semantically separate the need for processes from requirements management and change management, and to evaluate the implementation of new requirements separately.
The Fiori app included in the delivery is also worth mentioning. The app is a compressed version of the business request and unfortunately has no categorization elements.
The initial customer reactions are quite positive and give reason to hope that requirements management with SAP Solution Manager 7.2 will quickly establish itself as a fully integrated process.
