Configuration of SDM in Managed Services Project Case

7/25/2019 Configuration of SDM in Managed Services Project Case

1/14

Case Study

2015-02-03 Huawei Proprietary

For Internal Use Only Page1, Total14

HH

O

O

W

W

T

T

O

O

DD

E

E

F

F

I

I

N

N

E

E

T

T

H

H

E

E

PP

A

A

R

R

A

A

M

M

E

E

T

T

E

E

R

R

S

S

A

A

N

N

D

D

M

M

A

A

K

K

E

E

T

T

H

H

E

E

C

C

O

O

N

N

F

F

I

I

G

G

U

U

R

R

A

A

T

T

I

I

O

O

N

N

O

O

F

F

S

S

E

E

R

R

V

V

I

I

C

C

E

E

D

D

E

E

S

S

K

K

M

M

A

A

N

N

A

A

G

G

E

E

M

M

E

E

N

N

T

T

SS

YYSSTTEEMMIINNAA

MM

AANNAAGGEEDD

SS

EERRVVIICCEESS

P

P

R

R

O

O

J

J

E

E

C

C

T

T

Case Study

Version: 1.0


2/14

Case Study



Preface

This document gives details to support the configuration of one of the main tools

in a Managed Services Project as SDM (Service Desk Management), in old

versions named MOS7100.

These tools are used to document all the Network Operations executed by Huawei

Employees, Huawei Subcontractors and Customer Third Suppliers. Inside of the

configuration should be included all parameters needed to prepare any report and

classification requested by Customer and Huawei Internal Regulations.

According to Managed Services Projects and Procedures, we have three mainstypes of Network Operations:

Fault Management.

Performance Management.

Preventive Routines Management.

All these operations are regulated by the Contract between Huawei Solutions

Sales Department and Customer, inside of the Contract are specified the

conditions and responsibilities of Huawei and customer during the Contract

Period.

One of the main conditions of the contract is the Service Level Agreement (SLA),

in here we have the parameters to define the classification of all events by

service impact, response times, resolve times, routines frequency, network

performance parameters agreed and any other service indicator that customer

request and Huawei accept.

The contract parameters included in the last paragraph must be integrated to

Service Desk Management tool, and our objective is provide a guide of how to

define it.

Version Date Author Approver Remarks

1.0 January 30th, 2015 Javier Segura Edwin Salazar Final


3/14

Case Study



Contents

Preface ..............................................................................................2

Project Introduction .............................................................................4

Infrastructure Failures ....................................................................... 4

Access and Transmission Failures ........................................................ 4

Radiant System Failures ..................................................................... 4

Core Failures .................................................................................... 5

Definitions in Service Desk Management .................................................5

Fault Level ....................................................................................... 5

Fault Occur Time ............................................................................... 6

Fault Recovery Time .......................................................................... 6

Responsible of the Failure (Vendor) ..................................................... 7

Root Cause and Sub Cause ................................................................. 7

Other important parameters for SDM ......................................................9

Users organization and distribution ...................................................... 9

Sites information ............................................................................. 10

Rules for notifications ...................................................................... 12

SLA (Service Level Agreement) ......................................................... 13

Conclusions and Advantages of SDM Full Configured ............................... 14


4/14

Case Study



Project Introduction

In December 31th 2013 the Managed Services Contract of Telefonica Costa Rica

expired, several conditions changed with 2014 negotiation, and with this our

Service Desk Management and reports to customer had to change several

parameters to satisfy the new Scope of Work that Telefonica request.

According to the new contract, network faults must be divided in three groups:

Infrastructure Failures.

Access and Transmission Failures.

Radiant System Failures.

Core Failures.

Infrastructure Failures

Here is included all the faults that involve power equipments, sensors, cabinets,

air conditioning, physical problems in site security or access, temperature issues

and any other problem not related to Telecom Equipments.

Access and Transmission Failures

Faults affecting the transmission or base station equipments, this is related to

equipment boards and components, optical fiber or any other network cable

inside of the cabinet.

Radiant System Failures

In this category we have the failures that affect components between the

cabinets and the antennas in tower. For instance: RRUs, Jumpers, ODUs, IF or RF

Cables, RF and Microwave Antennas.

After this review, the next step is design how to separate this in Service Desk

Management and how to classify the internal categories of all failure types. This

was defined according to our criteria and approved by customer to negotiate the

content of all the services reports.


5/14

Case Study



Core Failures

In Core Room of the network we have the main equipments to provide all the

services to the end users, any failure in some of this equipments would beincluded in this category.

Definitions in Service Desk Management

There are several parameters to define in Service Desk Management that must be

related to the project, we have to analyze them one by one and find the

utilization of each one in the reports to classify and separate all the failures and

this will allow to create several reports and classifications depending of what we

need to analyze in the project.

For Telefonica Costa Rica Managed Services Project, after several meetings with

Customer Engineers, we include these parameters to analyze the project and

network status, and as a main purpose check weekly the SLA accomplishment:

Fault Level

Fault Occur Time

Fault Recovery Time

Responsible of the Failure (Vendor)

Root Cause

Sub Cause

Fault Level

Its to define the impact of the failure in the network. According to Telefonicas

Regional Standards, they have 5 Fault Levels:

Fault Level Name

Telefonica Standard)

Impact in

the Network

Description

SF1

Critical

Service Impact of 80 or more Sites.

SF2 Service Impact from 16 to 79 Sites.

SF3

Service Impact from 11 to 15 Sites.

SF4

Major Service Impact from 1 Cell to 10 Sites.

SSF

Minor Failure with no Service Impact.


6/14

Case Study



With this parameter now we can classify the failures according to its impact in the

network, but as indicated in Introduction, we still have to divide in Infrastructure,

Access and Transmission, Radiant System and Core. For this we divide the impact

of the network also by type of failure, causing 20 different types of Fault Levels:

Fault Level in SDM

SF1 - Acceso y Tx

SF2 - Acceso y Tx

SF3 - Acceso y Tx

SF4 - Acceso y Tx

SSF - Acceso y Tx

SF1 - Infraestructura




SSF - Infraestructura

SF1 - Sist. Radiante




SSF - Sist. Radiante

SF1 - Core

SF2 - Core

SF3 - Core

SF4 - Core

SSF - Core

Customer communicates in Spanish, for this all parameters are in that language.

Fault Occur Time

Is the time when the alarm appears in EMS (Element Management System).

Monitoring Engineers input in the tickets the time from EMS in SDM.

Fault Recovery Time

Time when the failure is resolved, its also obtained from EMS.


7/14

Case Study



Responsible of the Failure Vendor)

Here we include the company responsible of the failure, and this field is very

important because its the cases where we specify if are attributable to Huawei ornot. For Telefonica Costa Rica, we must include all these:

Responsibility of

Failures

Description

Optical Supplier A Optical Transmission supplier of Telefonica.

Compaa Electrica Power Supplier.

Huawei Faults caused by us or our equipments.

Telefonica Failures attributable to Telefonica or Telefonica

Enterprise Customers Department.Telefonica Empresas

Vandalismo Vandalism cases.

Global CrossingInternational Service Provider of Telefonica.

TIWS

Telecom Supplier XXX Failures caused by our competitors.

Tower Companies

These companies are the Towers owners, they rent the

sites field and build the towers structure. So Telefonica

and other operators can rent tower spots to install the

antennas.

They are responsible of all sites access and construction

issues.

Root Cause and Sub Cause

These parameters were included to specify more deeply the network failures, are

used also to separate the Infrastructure, Access and Tx and Radiant System

cases. Customer was very strict reviewing this, in order to classify with most

precision possible the failures. In the following table we can see the root cause

and sub causes included for this project:


8/14

Case Study




9/14

Case Study



Other important parameters for SDM

There is more information we need take in consideration to have a proper

configuration of SDM:

Users organization and distribution

Sites information

Rules for Notifications

SLA (Service Level Agreement)

Users organization and distribution

To create all project users in SDM, its very important analyze the project staff

organization and define the users distribution in the same way of the project.

According to the Managed Services Contract, the project staff is organized in this

way:

O&M Manager (Project Manager)

o NOC Manager

Back Office Engineers

Front Office Engineers

o FLM Manager

Field Maintenance Engineers

We must create the Project Organization in the system:


10/14

Case Study



In that image we can appreciate the internal Project Organization, but in most of

cases, we also need give access to customer, because they always want to check

by themselves any case they need. For our project, the customer request was

more than only the access, they asked receive SMS/Email notifications fromMOS7100 and/or SDM, so we needed to create their personal users and also

define some groups according to Failures Fault Levels and the people included in

the notification:

The instructions to create the users in the system are very clear, we just need to

follow the Import Template documents content and with that all the users will be

included with just one or more Excel files.

Sites information

One of the most important parameters creating the Tickets is the site

information, here is included the Site ID, Site Name, coordinates, region,

maintainer and any other key information we want to include for Front Office,

Back Office or Field Maintenance Engineers. If SDM is connected to WFM (Work

Force Management System, this is very useful because the FME can see all the

site information if his mobile phone.

Before include all the sites, we need to feel all the fields needed in the Resource

Parameters, here we define the most of information to be included in the tickets

workflow modules:


11/14

Case Study



All the parameters have their own file import template, this means once defined

we just include all in the Excel and import to the system.

One of the most important fields to define in sites is the Region, because here we

set who is in charge of the site maintenance. For Costa Rica Project, we classify

the sites in 3 Parent Regions and 13 Child Regions:

Every Child Region means a Field Maintenance Team.


12/14

Case Study



For every new site integrated to the project, first of all we need to classify it by

region, site type according to contract classification and any other parameter we

need.

Rules for notifications

SDM has the capability to send SMS and Email alerts any time we need, so with

this we can configure to send it automatically one or both communications to be

sent when the SDM operator submit the information.

This is a very specific work, because we have to configure all the rules we want

according to our needs. To avoid extent too much this document, we will take as

example the configuration of the notification of Critical TT Creation, the purpose

of this rule is send a SMS and Email every time that Front Office Engineer submit

a critical TT to SDM. The steps of the configuration are the following:

1. Set the moment when the rule have to be activated:

2. Set the condition to activate the rule. In our example case, is any time

that Front Office create a TT with SF1, SF2 or SF3 fault level, in all

categories:

3. Set the content of the messages we want to send, Its better include to

separated actions, one for Email and one for SMS:


13/14

Case Study



4. After all actions included, just save the changes and last step is configure

the name of the rule.

We can include all the rules we need; in our project we use some rules for

internal notifications and others for customer. This has to be used very carefully

because we need analyze the content we send to customer, keeping the

information security of the project.

SLA Service Level Agreement)

The SLA in the system helps to organize all the teams to provide a better service

to customer. With this in the system we can send notifications about SLA time

limitations during the failures, include colors in tickets that symbolize the SLA

status. There are some concepts we need to know to make the configuration:

Measure Item: its the formulas we want to calculate, its always a

subtraction of times, the most common is Required Finish Time that isthe Fault Recovery Time Fault Occur Time.

Target: the targets are the commitments we want to accomplish in the

project and with all the conditions we need. For Telefonica Costa Rica

case, we had to configure just the Required Finish Time for our types of

failures. Only Radiant System has 24 hours, the rest must be recovered in

3 hours.

Milestone: this is some time we want to define before finish the SLA time.

In our project we set it in 50% of the SLA Remaining Time.


14/14

Case Study



As specified in the beginning, we separate our types of failures with the Fault

Level; this means that to configure the SLA we just had to make conditions

according to the Fault Level to set the SLA time during the Trouble Ticket:

When we configure the conditions, we can include notifications for Milestone and

Target, this ensures that the staff assigned to solve the failure and the related

project staff receive the SLA status of the case at the half of time remaining and

also when the SLA expires. Actually we have SMS and Email for this, the

difference between both is the size of the message, SMS has less information

than Email.

Conclusions and Advantages of SDM Full Configured

With SDM or MOS7100 configured properly, we can get several kind of reports

and statistics of the project, also to all project staff we can review their

performance and attention to project activities, also they can receive notifications

about what they need to do in order to keep the project and network with the

best KPIs possible.

In customer relationship, these tools help to increase customer confidence in

Huawei, because its a formal tool that they can access any time and check

complete tracking of the project activities and also check the service and contract

status ensuring if we are accomplishing the terms aggreed or not.

Configuration of SDM in Managed Services Project Case

Documents

Transcript of Configuration of SDM in Managed Services Project Case