Service Interface Operation Process...

COPERNICUS MARINE ENVIRONMENT MONITORING SERVICE

CMEMS

NRT DU

Service Interface Operation Process Manual

Reference: CMEMS-NRTDU-SIOPM

Validated by: Vega Forneris (CNR) Document release number: 1.0 Date: 06/10/2017

Contributors : Richard Campbell (SERCO), Alessandra Paciucci (SERCO)

NRT DU Service Interface Operation Process

Manual

Ref : CMEMS-NRTDU-SIOPM

Date : 6-10-2017

Issue : Draft

COPERNICUS MARINE ENVIRONMENT MONITORING SERVICE PAGE 2/ 16

CHANGE RECORD

Issue Date § Description of Change Author

1.0

draft

06/10/2017

all First version of document R. Campbell (SERCO) A. Paciucci (SERCO)


Manual


Date : 6-10-2017

Issue : Draft


TABLE OF CONTENTS

I Scope ................................................................................................................................................................. 6

II Service Desk organisation ................................................................................................................................ 7

III Local operation processes .......................................................................................................................... 10

III.1 Request Fulfilment .................................................................................................................................... 11

III.2 Event and Incident Management ............................................................................................................. 11

III.3 Problem Management ............................................................................................................................... 14

III.4 Service Level Management....................................................................................................................... 15

IV TRAINING ..................................................................................................................................................... 16


Manual


Date : 6-10-2017

Issue : Draft


GLOSSARY AND ABBREVIATIONS

CMEMS Copernicus Marine Environment Monitoring Service

DU Dissemination Unit

ITIL Information Technology Infrastructure Library

OPM Operation Processes Manual

PC Production Center

PU Production Unit

SIOPM Service Interface Operation Processes Manual

SLA Service Level Agreement


Manual


Date : 6-10-2017

Issue : Draft


APPLICABLE AND REFERENCE DOCUMENTS

Ref Title Date / Issue

DA 1 Statement of Work For

Dissemination Unit Operations

August 2017

1.0

DA 2 CMEMS-SCE-OPM Operation Processes Manual

(OPM)

March 2017 V1.1

DA 3 CMEMS-NRTDU-MP

Management Plan for

NRT DU

Oct 2017 V1.0

DA 4 CMEMS-NRTDU-CMP Configuration Management Plan

for NRT DU

Oct 2017 V1.0

DA 5 CMEMS-NRTDU-ADD Architecture Design Document Oct 2017 V1.0-draft


Manual


Date : 6-10-2017

Issue : Draft


I SCOPE

The purpose of this "Service Interface Operation Process Manual" (SIOPM) is to capture the details of the service that will be delivered in order that they will be able to provide the necessary support to the Service Management and therefore CMEMS users.

In the frame of CMEMS, a Service Interface Operational Process Manual (SIOPM) describes how each sub-system of CMEMS (Production Units/Dissemination Units/Central Information System) will participate in the processes as described in the CMEMS Operations Process Manual [DA 2].

The Central CMEMS Service Management interacts with sub-system in a variety of ways (e.g. incident management). These interactions are performed according to commitments that are defined in the SoW [DA 1].

The SIOPM describes the Service Interface and furthermore goes on to describe how that interface is managed and who will be responsible for each aspect of that management.

The SIOPM is related to the Operations Processes Manual [DA1].


Manual


Date : 6-10-2017

Issue : Draft


II SERVICE DESK ORGANISATION

At day 1, the DU Operator will provide a centralized (single point of contact) CMEMS DU Service Desk (CMEMS-NRT-DU-SD) and a Local Service Desk per sub-DU (NRT-YYY-DU-SD) in charge of specific services/interfaces, organized in a hierarchical structure. The CMEMS-NRT-DU-SD will interface with (and will ensure a second level Service Desk to) the CMEMS Service Desk (CMEMS SD) and CMEMS PUs. NRT-YYY-DU-SD will provide third level Service Desk.

Figure 1: DU Service Desk structure

Who operates the Local Service Desk?

DU-Servicedesk compromising

1. OPS Manager

2. Dissemination Unit Service Desk team (DU SD) ( 2nd line)

3. Monitoring and Control team

4. Dissemination Unit Sub (MFC/OBS/INS/DU infra) support team (3rd level)

All Service Desk will be operated during working hours (8hours; 5/7), and by different partners, as shown in Figure 1 for providing a more specialized expertise.


Manual


Date : 6-10-2017

Issue : Draft


What tools do you use to record requests (e.g. spreadsheet, database)?

Customised ITMS tool based on CMDBuild Open source project

The service management tool will be based on the open source CMDBuild project software (GPL) , and although initially we are only using the service management aspects (Incident/Problem/Request ) this can be extended to manage custom change and configuration processes.

The project also uses highly interoperable technologies such as SOAP web-service which exposes all the methods primitive data management and JSR portlet to integrate the CMDB into external collaborative portals.

Serco have many years’ experience in developing CMDBuild service management tools, offering specific functionality and work flows.

Configuration items could be tailored to be datasets, software items or infrastructure assets, so that incident, problems and change requests could then be associated with specific configuration items depending on the service requirements.

What tools do you use to record incidents?

Customised ITMS tool based on CMDBuild Open source project to manage all ITSM aspects. A screenshot is provided as an example below.

As such calls will follow the standard ITIL statuses as shown in Table 1.

Table 1 Call Statuses

Type of Request

Status Incident Problem Change Request

New X X X X

Assigned X X X X

In Progress X X X X

Pending X X X X

Completed X X X

Resolved X

Closed X X X X

Rejected X X X X

Cancelled X X X X

This should ensure that the DU service desk should be to communicate easily with the Central and other Local Service desks as necessary.

Calls can be of two priorities


Manual


Date : 6-10-2017

Issue : Draft


• ROUTINE: does not impact operations nor affects the service performance and the call is usually related to a single reported user or incident.

• CRITICAL: may impact the operational service if timely actions are not undertaken (e.g. system instabilities, crash of non-operational systems) affecting a service or multiple users.

And will be treated with the appropriate urgency, in line with the services response requirements.

Figure 1 Example screenshot of an existing Incident management tool based on CMDBuild

What hours are the service desk manned and which days?

Monday to Friday, 9am to 5pm CEST/CET – in line with CSD

What arrangements (if any) do you have for support outside of these hours?

Monday to Friday, service covers 8:30 to 5:30 as extended support.

Specific request for outside support can be requested to be addressed on a case by case basis.

Define which is your commitment in the response time of Service Desk for requests from CMEMS Service Desk (it should be less than 1 day in working hours)

For questions coming from the CMEMS Service desk, the DU Service Desk shall provide a first response (complete) within 1 working day within 95% of questions. We will make every effort to respond to all calls within 1 working day, but we can only commit to this level of performance for a maximum of 500 questions per year and 20 questions per day. This can be reviewed at the first service review.


Manual


Date : 6-10-2017

Issue : Draft


Please provide your local service desk email address

[email protected]

III

mailto:[email protected]


Manual


Date : 6-10-2017

Issue : Draft


LOCAL OPERATION PROCESSES

III.1 Request Fulfilment

PROCESS OWNER: Alessandra Paciucci

Describe how the following requests will be dealt with:

How do you manage requests/feedbacks raised by CMEMS Service Desk about services? E.g. complaint about time taken to get access to service

Any enquiries coming from the Central Service Desk to the Local Service Desk relating to requests and feedbacks can be handled by email or phone. As a single point of contact – the DU Operations manager will be responsible for coordinating all responses.

In all of the cases, the Local Service Desk will record the requests into the ITSM Tool,, in the case of a complaint the incident will be identified as such so it can be managed and reported on accordingly. Specifically for complaints the DU SD will immediately contact the source of the complaint asking more details as possible on the cause that generated the dissatisfaction, and whenever needed the original request will be re-opened.

• The assignee will perform a further and deeper investigation on the new requester feedback, up to address them and satisfy the request.

• Before set the request to Resolved/Completed status, the Service Desk will contact the requester to ensure to have reached his/her expectations.

In all cases the DU operations manager will coordinate and update the CMEMS Service Desk.

III.2 Event and Incident Management

SUB SYSTEM PROCESS OWNER: Alessandra Paciucci


Manual


Date : 6-10-2017

Issue : Draft


Incident arrives from CMEMS Service Desk (email/

phone/ticket TBC)

Ticket resolved at DU SD

No

Ticket closed

Email to acknowledge the

ticket

Ticket open in ITSM

Identify the sub-SD and assign to it

Inform the originatorYes

Have the Sub-Du closed the ticket

Inform the originator

Yes Close the ticket

Chase the sub-DU and wait for an

update

Figure 2 : Use Case of Operational Processes

What is your incident management process?

ITIL Compliant process.

1. Incident can arrive by email or phone, by be reported resulting from a monitoring alert

2. Incident opened in the ITSM tool and assigned to the DU Service Desk (DU SD)

3. If the Response can be resolved by the DU SD directly – the request will be put in resolved status and the entity that raised the call will be informed and asked to confirm that the ticket can be closed. And then jump to 6

4. If the ticket cannot be resolved by DU SD then it will be passed to a relevant Sub-DU service team and reassigned within the ITSM tool, with a time stamp

5. The Sub-DU SD will resolve the call and update the ITSM passing back control to the DU SD. In the case that more time is needed the sub-DU will inform the DU SD , who will liaise with CMEMS


Manual


Date : 6-10-2017

Issue : Draft


and the user raiding the request to provide progress report until the problem will be resolved. In the case that the service needs unplanned outage the relevant form will be filled and passed to CMEMS. Once approved the corrective action will be undertaken. These actions will continue until the incident appears to be resolved. At which case the CMEMS Service Desk is informed and the relevant entity is asked to close the call.

6. In the case that the raiser confirms the incident is resolved the ticket will be placed into Closed state and the process closed. In the case that the entity that raised the ticket is not satisfied . the DU SD will update the ticket , it will be placed in the open status and the process will jump back to part 2.

Once an incident is identified, please specify when the local service desk sends an “incident form” & ”plan service outage” form filled to the CMEMS Service Desk (even with few fields filled in)

Keeping the CMEMS Service Desk informed on incidents that have a large impact (or require a service interrupt) is of paramount importance , to allow that the overall service is coordinated and that users and other components of the CMEMS are aware.

When investigating tickets (either passed from the CMEMS Service Desk or raised by Alert) as soon as the DU SD has identified that the incident will have an impact on the multiple users or services they will inform the CMEMS service desk using an Inc & PMO form

Initially the incident form will include an identifier, impacted areas or users, name of reporter, date and description.

As more information is collected and the resolution of the incident is identified the form will be updated and sent to the CMEMS Service Desk.

In the case that service needs to be interrupted then a PSO part form will be presented to the CMEMS service as soon as the required actions have been identified.

At this point the DU Service and Operations managers will liaise with the CMEMS Service desk to agree the urgency and schedule of the recovery actions and service interruption ( when applicable).

Describe how an incident will be communicated within DU organisational structure as well as the interaction with the CMEMS Service Desk. These might include:

• Operational Events

• Availability

• Timeliness

Any event or incident that impacts on service availability, performance or outages, the CMEMS service desk will be kept up to date by the issuing of the INC and PSO forms. For major incidents the CMEMS service desk will be updated on an agreed schedule (default to every 2 hours if no specific information given).

The DU SD the DU Service team will be informed via the following mechanism’s.


Manual


Date : 6-10-2017

Issue : Draft


o Distribution list will be used to email all interested parts within the DU Service team

o Information relating to the incident will be placed on the CIS Portal / Central web portal

o Where specific systems or components are affected the Service Desk team will ensure that the relevant manager is directly informed – via phone or in person.

o The used ITSM system will also have a news item relating to the specific incident

What systems do you have in place to monitor IT service availability?

The main tool to monitor availability will be the Serco developed SYSMA tool. It will be used to monitoring real-time alarms as well as long term data-warehouse for the monitored parameters from each DU service ( customizable). In addition, the following features are available:

monitor different applications of the DU service by means of specific parameters;

report these information using data stored in real-time and long-term databases;

provide feedback and alert the authenticated users to significant events related to the DU operations.

The system can report where expected throughput is not in line with expected performance. The following screenshot shows an example of the SYSMA application monitoring subsystems where number of products can be monitored very easily ( and alerts raised) so that preventative actions can be taken before the service is impacted.

Figure 3: example of SYSMA application monitoring

III.3 Problem Management



Manual


Date : 6-10-2017

Issue : Draft


Explain how problems will be investigated.

Recurring or unresolved issues will be classified as problems that need to be resolved off-line with respect to the incident management process. The Problem Management process will be carried out to ensure a root cause analysis is performed, with the involvement of 2nd and 3rd line support and software providers/maintainers as necessary. The process will aim to provide solutions to finally resolve the issues and if necessary to produce interim workaround solutions. The analysis and solutions identified will take into account the end-to-end scope of the process in which the problem is embedded. Solutions will be analysed considering impacts on data, software, hardware, configuration or documentation, dependencies and interfaces affected throughout the end-to-end process chain, costs and timescales, etc. and relevant trade-offs. Change proposals will be prepared as necessary for input to the change management process in order to select, agree and schedule cost effective, practical and durable solutions for implementation. Depending on the extent, impacts and criticality of the proposed solution, CMEMS Service Desk Manager will be included in this loop. Upon this agreement the DU Service or operation manager will then commission the remedial activities, take the necessary actions to dispatch their execution, communicating with all the relevant parties to inform and delegate them as necessary.

Who will be responsible for providing information to the top level

The process will be managed by operations manager and depending on the impact analysis will be escalated to the service manager.

Describe any system, tools or templates that will be used to record and track problems, known errors and work around and their resolution.

Known Errors and Service Desk Operational Procedures will be recorded into the relevant Databases and included into the ITSM Tool, this will allow the DU service desk operator to verify as 1st step of the investigation that it is something resolvable with a known and fast reaction, providing so assessment and wherever possible, the resolution to the end-users in the fastest way possible.

III.4 Service Level Management


Document who will be responsible for producing service reports.

Operations manager Alessandra Paciucci

Describe the process for how data to support the Service report will be provided to the person responsible for creating Service report.

All data relating to incidents, problems and requests is held in the ITSM as part of the underlying RDBMS. The required data can will be extracted and manipulated in EXCEL or other reporting tools to ensure that the service report covers all the required information.

Describe the process for how information in the Service report will inform.

The report will inform by presenting the following information (Draft to be agreed/tailored with CMEMS Service desk management).

Dashboard (DU SD at a glance) Statistics


Manual


Date : 6-10-2017

Issue : Draft


o Number of tickets handled / Per sub-system or area / Sources of ticket / etc.

o Tickets handled within the KPI levels

o Complaints and how these have been managed

Major activities for this period

o Major successes

o Results of planned activities

o Service interrupts

o Ongoing problems ( and recovery plans)

Planned activities for the next period

IV TRAINING

Describe how teams will be kept up to date with process changes so that they can continue to participate in processes?

Teams will be kept up to date with the following mechanisms:

o Before any go-live changes are implemented the proposed change will be discussed with the CMEMS Service Desk Management and a scope and schedule agreed for any proposed implementation, (with all accompanying planning and documentation).

o As soon as the process is updated the CMEMS service desk manager will be informed of successful update.

o Affected staff will be given access to the new processes and training provided ( if necessary).

o All DU staff will be informed of changes to processes and procedures. This information will be managed by the operations manager and will be distributed to all DU sub-system staff

o Regular team meetings will inform operational staff on all process changes and the impact on their activities and roles.

Service Interface Operation Process...

Documents

Transcript of Service Interface Operation Process...