|
|
| Line 1: |
Line 1: |
| {{ITSM_menubar}}
| | #REDIRECT[[EGI_ITSM_Requirements#Process-specific_requirements]] |
| | |
| {{ITSM_process_menubar}} {{TOC_right}}
| |
| | |
| <br>
| |
| | |
| This page is providing process-specific requirements.
| |
| | |
| <br>
| |
| | |
| {| class="wikitable"
| |
| |-
| |
| | '''No'''<br>
| |
| | '''Description'''<br>
| |
| | '''Status'''<br>
| |
| | '''Add information'''<br>
| |
| |-
| |
| | colspan="4" | '''PR1 Service Portfolio Management (SPM)'''<br>
| |
| |-
| |
| | 1.1<br>
| |
| | A service portfolio shall be maintained. All services shall be specified as part of the service portfolio.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 1.2<br>
| |
| | Design and transition of new or changed services shall be planned. <br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 1.3<br>
| |
| | Plans for the design and transition of new or changed services shall consider timescales, responsibilities, new or changed technology, communication and service acceptance criteria.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 1.4<br>
| |
| | The organisational structure supporting the delivery of services shall be identified, including a potential federation structure as well as contact points for all parties involved.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | colspan="4" | '''PR2 Service Level Management (SLM)'''<br>
| |
| |-
| |
| | 2.1<br>
| |
| | A service catalogue shall be maintained.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 2.2
| |
| | For all services delivered to customers, SLAs shall be in place.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 2.3
| |
| | SLAs shall be reviewed at planned intervals.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 2.4
| |
| | Service performance shall be evaluated against service targets defined in SLAs.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 2.5
| |
| | For supporting services or service components provided by federation members or groups be longing to the same organisation as the service provider or external suppliers, OLAs and UAs shall be agreed.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 2.6
| |
| | OLAs and UAs shall be reviewed at planned intervals.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 2.7
| |
| | Performance of service components shall be evaluated against operational targets defined in OLAs and UAs.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | colspan="4" | '''PR3 Service Reporting Management (SRM)'''
| |
| |-
| |
| | 3.1<br>
| |
| | The specification of each service report shall include its identity, purpose, audience, frequency, content, format and method of delivery.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 3.2<br>
| |
| | Service reports shall be specified and agreed with their recipients.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 3.3<br>
| |
| | Service reports shall be produced. Service reporting shall include performance against agreed targets, information about significant events and detected nonconformities.
| |
| |
| |
| | <br>
| |
| |-
| |
| | colspan="4" | '''PR4 Service Availability & Continuity Management (SACM)'''
| |
| |-
| |
| | 4.1<br>
| |
| | Service availability and continuity requirements shall be identified taking into consideration SLAs.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 4.2<br>
| |
| | Service availability and continuity plans shall be created and maintained.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 4.3<br>
| |
| | Service availability and continuity planning shall consider measures to reduce the probability and impact of identified availability and continuity risks.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 4.4<br>
| |
| | Availability of services and service components shall be monitored.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | colspan="4" | '''PR5 Capacity Management (CAPM)'''<br>
| |
| |-
| |
| | 5.1<br>
| |
| | Service capacity and performance requirements shall be identified taking into consideration SLAs.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 5.2<br>
| |
| | Capacity plans shall be created and maintained.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 5.3<br>
| |
| | Capacity planning shall consider human, technical and financial resources.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 5.4<br>
| |
| | Performance of services and service components shall be monitored based on monitoring the degree of capacity utilisation and identifying operational warnings and <br>exceptions.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | colspan="4" | '''PR6 Information Security Management (ISM)'''<br>
| |
| |-
| |
| | 6.1<br>
| |
| | Information security policies shall be defined.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 6.2
| |
| | Physical, technical and organizational information security controls shall be implemented to reduce the probability and impact of identified information security risks.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 6.3
| |
| | Information security policies and controls shall be reviewed at planned intervals.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 6.4
| |
| | Information security events and incidents shall be given an appropriate priority and managed accordingly.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 6.5
| |
| | Access control, including provisioning of access rights, for information-processing systems and services shall be carried out in a consistent manner.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | colspan="4" | '''PR7 Customer Relationship Management (CRM)'''<br>
| |
| |-
| |
| | 7.1<br>
| |
| | Service customers shall be identified.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 7.2
| |
| | For each customer, there shall be a designated contact responsible for managing the customer relationship and customer satisfaction.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 7.3
| |
| | Communication mechanisms with customers shall be established.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 7.4
| |
| | Service reviews with the customers shall be conducted at planned intervals.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 7.5
| |
| | Service complaints from customers shall be managed.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 7.6
| |
| | Customer satisfaction shall be managed.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | colspan="4" | '''PR8 Supplier and Federation member Relationship Management (SFM)'''<br>
| |
| |-
| |
| | 8.1<br>
| |
| | Suppliers and federation members shall be identified.
| |
| |
| |
| | <br>
| |
| |-
| |
| | 8.2
| |
| | For each supplier and federation member, there shall be a designated contact responsible for managing the relationship with the supplier and federation member.<br>
| |
| |
| |
| | <br>
| |
| |-
| |
| | 8.3
| |
| | Communication mechanisms with suppliers and federation members shall be established.
| |
| |
| |
| |
| |
| |-
| |
| | 8.4
| |
| | Supplier and federation member performance shall be monitored.
| |
| |
| |
| |
| |
| |-
| |
| | colspan="4" | '''PR9 Incident & Service Request Management (ISRM)'''
| |
| |-
| |
| | 9.1
| |
| | All incidents and service requests shall be registered, classified and prioritized in a consistent manner.
| |
| |
| |
| |
| |
| |-
| |
| | 9.2
| |
| | Prioritization of incidents and service requests shall take into account service targets from SLAs.
| |
| |
| |
| |
| |
| |-
| |
| | 9.3
| |
| | Escalation of incidents and service requests shall be carried out in a consistent manner.
| |
| |
| |
| |
| |
| |-
| |
| | 9.4
| |
| | Closure of incidents and service requests shall be carried out in a consistent manner.
| |
| |
| |
| |
| |
| |-
| |
| | 9.5
| |
| | Personnel involved in the incident and service request management process shall have access to relevant information including known errors, workarounds, configuration and release information.<br>
| |
| |
| |
| |
| |
| |-
| |
| | 9.6
| |
| | Users shall be kept informed of the progress of incidents and service requests they have reported.<br>
| |
| |
| |
| |
| |
| |-
| |
| | 9.7
| |
| | There shall be a definition of major incidents and a consistent approach to managing them.
| |
| |
| |
| |
| |
| |-
| |
| | colspan="4" | '''PR10 Problem Management (PM)'''
| |
| |-
| |
| | 10.1
| |
| | Problems shall be identified and registered based on analysing trends on incidents.
| |
| |
| |
| |
| |
| |-
| |
| | 10.2
| |
| | Problems shall be investigated to identify actions to resolve them or reduce their impact on the services.
| |
| |
| |
| |
| |
| |-
| |
| | 10.3
| |
| | If a problem is not permanently resolved, a known error shall be registered together with actions such as effective workarounds and temporary fixes.
| |
| |
| |
| |
| |
| |-
| |
| | 10.4
| |
| | Up-to-date information on known errors and effective workarounds shall be maintained.<br>
| |
| |
| |
| |
| |
| |-
| |
| | colspan="4" | '''PR11 Configuration Management (CONFM)'''
| |
| |-
| |
| | 11.1
| |
| | Configuration item (CI) types and relationship types shall be defined.
| |
| |
| |
| |
| |
| |-
| |
| | 11.2
| |
| | The level of detail of configuration information recorded shall be sufficient to support effective control over CIs.
| |
| |
| |
| |
| |
| |-
| |
| | 11.3
| |
| | Each CI and its relationships with other CIs shall be recorded in a configuration management database (CMDB).
| |
| |
| |
| |
| |
| |-
| |
| | 11.4
| |
| | CIs shall be controlled and changes to CIs tracked in the CMDB.
| |
| |
| |
| |
| |
| |-
| |
| | 11.5
| |
| | The information stored in the CMDB shall be verified at planned intervals.
| |
| |
| |
| |
| |
| |-
| |
| | 11.6
| |
| | Before a new release into a live environment, a configuration baseline of the affected CIs shall be taken.
| |
| |
| |
| |
| |
| |-
| |
| | colspan="4" | '''PR12 Change Management (CHM)'''
| |
| |-
| |
| | 12.1
| |
| | All changes shall be registered and classified in a consistent manner.
| |
| |
| |
| |
| |
| |-
| |
| | 12.2
| |
| | All changes shall be assessed and approved in a consistent manner.
| |
| |
| |
| |
| |
| |-
| |
| | 12.3
| |
| | All changes shall be subject to a post implementation review and closed in a consistent manner.
| |
| |
| |
| |
| |
| |-
| |
| | 12.4
| |
| | There shall be a definition of emergency changes and a consistent approach to managing them.
| |
| |
| |
| |
| |
| |-
| |
| | 12.5
| |
| | In making decisions on the acceptance of requests for change, the benefits, risks, potential impact to services and customers and technical feasibility shall be taken into consideration.
| |
| |
| |
| |
| |
| |-
| |
| | 12.6
| |
| | A schedule of changes shall be maintained. It shall contain details of approved changes, and proposed deployment dates, which shall be communicated to interested <br>parties.
| |
| |
| |
| |
| |
| |-
| |
| | 12.7
| |
| | For changes of high impact or high risk, the steps required to reverse an unsuccessful change or remedy any negative effects shall be planned and tested.
| |
| |
| |
| |
| |
| |-
| |
| | colspan="4" | '''PR13 Release & Deployment Management (RDM)'''
| |
| |-
| |
| | 13.1
| |
| | A release policy shall be defined.
| |
| |
| |
| |
| |
| |-
| |
| | 13.2
| |
| | The deployment of new or changed services and service components to the live environment shall be planned with all relevant parties including affected customers.
| |
| |
| |
| |
| |
| |-
| |
| | 13.3
| |
| | Releases shall be built and tested prior to being deployed.
| |
| |
| |
| |
| |
| |-
| |
| | 13.4
| |
| | Acceptance criteria for each release shall be agreed with the customers and any other relevant parties. Before deployment the release shall be verified against the agreed acceptance criteria and approved.
| |
| |
| |
| |
| |
| |-
| |
| | 13.5
| |
| | Deployment preparation shall consider steps to be taken in case of unsuccessful deployment to reduce the impact on services and customers.
| |
| |
| |
| |
| |
| |-
| |
| | 13.6
| |
| | Releases shall be evaluated for success or failure.
| |
| |
| |
| |
| |
| |-
| |
| | colspan="4" | '''PR14 Continual Service Improvement Management (CSI)'''
| |
| |-
| |
| | 14.1
| |
| | Opportunities for improvement shall be identified and registered.
| |
| |
| |
| |
| |
| |-
| |
| | 14.2
| |
| | Opportunities for improvement shall be evaluated and approved in a consistent manner.
| |
| |
| |
| |
| |
| |}
| |
| | |
| [[Category:EGI_ITSM]] | |
The wiki is deprecated and due to be decommissioned by the end of September 2022.