Request for Service Process¶
The Request for Service process enables users or user groups (=Requester) to announce their need for a service which is not yet offered in Helmholtz Cloud. Therefore, the primary goal of this process is to get an idea of which services are required from user side in order to find possible service providers for such a service. A secondary goal is to collect such needed services in a structured way, with a comparable level of information for each request. The Request for Service process helps HIFIS to better understand the user’s needs for services and in consequence to increase the quality of the Service Portfolio.
The roles involved in the Request for Service process are: the Requester (from or accross Helmholtz Centre(s)), the Service Integration Manager (HIFIS) and the Servic Portfolio Manager (HIFIS).
The trigger for the Request for Service process is the need from the Requester for a service which is not yet offered in Helmholtz Cloud.
Announcing their interest should be conducted via mail to firstname.lastname@example.org. The Requester is asked to provide some basic information and a general use case for the service required in Helmholtz Cloud to HIFIS. Additionally, the Requester needs to ensure that data handled within the potential service is allowed from the Requester’s centre side to be handled in Helmholtz Cloud. The mail to email@example.com will generate a ticket in Zammad, thus enabling the Service Portfolio Manager to roughly check whether the requested service will fulfill exclusion criteria described in the Onboarding process description. Please note that there is only a quite rough check possible at this point of the process. Anyway, it is important to inform the Requester this early in the process if there are concerns on exclusion criteria fulfillment. It is then left to the Requester whether they want to proceed with the Request for Service process.
After the rough exclusion criteria check, it is necessary for the Service Portfolio Manager to check whether demand for a similar service has already been announced in the past. If there is already similar demand documented, the Service Portfolio Manager will inform the Requester about existing demand, check the status quo of the corresponding request for service (e.g. if a service provider has already been found/not) and establish a connection between the two Requesters (so they can e.g. work out requirements together). In this case, the Request for Service process ends here.
If no similar demand exists yet, HIFIS Origanzational will ask the Requester to fill out the Request for Service Form, giving HIFIS much more details on the required service. It is not necessary to fill in each and every field - the Requester is asked to fill in all information yet known. The form is more about giving Requesters food for thought on which topics they may need to think about. As the Request for Service Form includes both organisational and technical information, both Service Portfolio Manager and Service Integration Manager may offer their support to the Requester to fill out the form together (e.g. in interview format). HIFIS should try to find out the requirements to be able to also recommend other services fulfilling these requirements - they should keep people from asking for a specific software which provide the same functionality another service in Helmholtz Cloud already offers.
As soon as the Request for Service Form is received by HIFIS, both Service Portfolio Manager and Service Integration Manager should check the information given for completeness and clarity. If required, they may clarify unclear points in dialogue with the Requester. Also, they need to check whether the service is going to fulfill exclusion criteria or whether there is a show stopper. If there is a show stopper, it is left to the Requester whether they want to proceed in the Request for Service process. When everything is fine, the Service Portfolio Manager will put the Request for Service to the already existing Requests for Service List. The Request for Service List will be publically available, e.g. in Helmholtz Cloud Portal. Users should then be able to e.g. like a Request for Service to prioritize it - anyway this functionality is not yet established - the tools for prioritization still need to be figured out. What is yet clear is that Requests for Service should be prioritized in some way – may be via “surveys” on HIFIS website, announcements in regularly meeting Helmholtz working groups etc. by actual users. This gives potential service providers the chance to see which service is required most and therefore for which service they may want to become service provider.
To stay updated, service providers should receive notification if a new service is added to the Request for Service List – as they may want to provide such a service. It is not yet clearly defined who should be informed on service provider side - first ideas are IT heads and centre contacts of the Helmholtz centres. Another idea is to regularly present a a bunch of Requests for Services/ use cases to SAB.
However, as soon as a service provider for a service is found, the Service Onboarding process can be initiated.