Процесса устранения неисправностей ресурсов сетей телекоммуникаций ао «казахтелеком» (версия 5)

СТАНДАРТ АО «КАЗАХТЕЛЕКОМ»

 

 

 

РЕГЛАМЕНТ

ПРОЦЕССА УСТРАНЕНИЯ НЕИСПРАВНОСТЕЙ РЕСУРСОВ СЕТЕЙ ТЕЛЕКОММУНИКАЦИЙ АО «КАЗАХТЕЛЕКОМ» (Версия 5)

(Включает поправки из последних протоколов совещаний)

 

СТ АО 804209 4/020 -2015

 

Алматы

 

1 РАЗРАБОТАН Департаментом управления технологическими процессами Центрального аппарата АО «Казахтелеком»

2 УТВЕРЖДЕН Приказом АО «Казахтелеком» от____ _________ 2013 года № ____

 

3 ВВЕДЕН в действие _______________________

 

4 ВВЕДЕН ВЗАМЕН Регламента процесса устранения неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком, утв. Приказом от 15.07.2013года № 270

 

 

 

Настоящий Cтандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения АО «Казахтелеком».

 

Содержание

Содержание.. 3

1 Общие положения.. 8

2 Термины... 8

3 Cокращения.. 11

4 Ресурсы, используемые для реализации процесса.. 12

5 Наименования функциональных групп.. 13

6 Описание функциональности системы... 18

ПБ в статус «Развитие» переводится действием «Перевести в статус Развитие» аналитиками ГЦОУСТ в тех случаях, когда филиалу требуется реализовать новую функциональность и/или услугу т.е. возникает необходимость разработки нового ПО или проведения закупа дополнительного оборудования. При этом указанные вопросы не могут быть решены в рамках ТП, и как следствие требуется разработать новый проект и определить источники финансирования. Такие ПБ не должны оказывать влияние или приводить к влиянию на коммерческие сервисы кампании. 20

7 Распределение функциональных обязанностей между участниками процесса.. 21

7.1 Обязанности аналитика ЦУС уровня 1. 21

7.2 Обязанности аналитика ЦУС уровня 1 в роли супервизора оперативного управления (ОУ) 22

7.3 Обязанности аналитика ЦУС уровня 1 в роли аналитика по мониторингу производительности сети.. 22

7.4 Обязанности работников подразделений Технического блока филиала в роли аналитика ЦУС уровня 2 23

7.5 Обязанности работников подразделений Технического блока филиала в роли аналитика ЦУС уровня 3 23

7.6 Общие обязанности работников подразделений Технического блока филиала в роли аналитиков ЦУС уровней 2 и 3 23

7.7 Обязанности работников подразделений Технического блока в роли исполнителя. 24

7.8 Обязанности работников ОС ГЦУСТ в роли аналитика ЦУС уровня 1. 24

7.9 Обязанности работника ОС ГЦУСТ в роли супервизора оперативного управления (ОУ) 25

7.10 Обязанности работника ОС ГЦУСТ в роли аналитика по мониторингу производительности сети.. 25

7.11 Обязанности работника в роли супервизора технической поддержки (ТП) 26

7.12 Обязанности аналитика ЦУС уровня 1 в роли менеджера. 27

7.13 Порядок взаимодействия персонала объединенных смен ГЦУСТ и ОДС 27

7.13.1 Общие положения. 27

7.13.2 Распределение функциональных обязанностей объединенных смен ГЦУСТ и ОДС.. 28

7.13.3 Взаимодействие объединенных смен ГЦУСТ и ОДС: 28

8 Порядок взаимодействия подразделений (участников процесса) в процессе устранения неисправностей ресурсов сетей телекоммуникаций 30

8.1 Формирование и открытие (регистрация) проблемного билета. 30

8.2 Создание ПБ при невыполнении условий РНР.. 31

8.3 Правила регистрации ПБ при повреждении нескольких потоков. 31

8.4 Правила регистрации проблем функционирования информационных систем СУСТ.. 32

8.5 Правила регистрации ПБ при массовом поступлении заявок ЦБР. 32

8.6 Правила регистрации обращений клиентов «Гос. ПС» и VIP-клиентов. 32

8.7 Регистрация обращений абонентов категории «VIP-клиент». 33

8.8 Правила регистрации обращений сторонних операторов. 34

8.9 Правила регистрации проблем с терминальным оборудованием. 34

8.10 Правила регистрации проблем с связанных с начислением по услугам IDTV. 35

8.11 Правила перевода ПБ в статус «Развитие». 35

8.11.1 ПБ в статус «Развитие» переводится действием «Перевести в статус Развитие» аналитиками ГЦОУСТ в тех случаях, когда филиалу требуется реализовать новую функциональность и/или услугу т.е. возникает необходимость разработки нового ПО или проведения закупа дополнительного оборудования. При этом указанные вопросы не могут быть решены в рамках ТП, и как следствие требуется разработать новый проект и определить источники финансирования. Такие ПБ не должны оказывать влияние или приводить к влиянию на коммерческие сервисы кампании. 35

8.11.2 ПБ, решение по которым связано с закупками нового, модернизацией существующего оборудования, ремонтом/отсутствием ЗИП, а также ПБ, не связанные с проблемами эксплуатации оборудования или услуг, переводу в статус «Развитие» не подлежат. Данные ПБ необходимо решать в соответствии с п.8.15.5 Регламента СУПБ. 35

8.11.3 Порядок выполнения действий: 36

8.11.4 Перевод ПБ из статуса "Развитие" в статус - "В работе" должен производиться аналитиками филиалов самостоятельно, без проведения согласования с ДГЦОУСТ. 36

8.11.5 Контрольный срок нахождения ПБ в данном статусе устанавливается аналитиками ГЦОУСТ в ручном режиме на основании сроков указанных в подтверждающих документах. При истечении контрольного срока ПБ автоматически возвращается в статус "В работе". При этом общий срок нахождения ПБ в данном статусе не обнуляется (накапливается). 37

8.11.6 ПБ в статус «Развитие» может переводиться только при нахождении ПБ в состоянии «2б» (Предупреждение). 37

8.11.7 В случае необходимости продления контрольного срока (до его окончания) к ПБ должны быть приложены подтверждающие документы, в поле «Ход работы» необходимо внести соответствующую запись и выполнить действие «Эскалировать ПБ в группу «Развитие» ГЦОУСТ». 37

8.11.8 При возникновении аварийной ситуации, по проблеме, описанной в имеющемся ПБ в статусе "Развитие", филиал обязан открыть новый ПБ, в котором должны быть зафиксированы все статусы объекта ("1" -Авария, "2" - Повреждение, "11" - КРП). Данные ПБ запрещено "прикреплять" к ПБ в статусе "Развитие". 37

8.12 Диспетчеризация ПБ внутри филиала аналитиком ЦУС уровня 1. 38

8.13 Закрытие ПБ аналитиком ЦУС уровня 1. 38

8.14 Эскалация ПБ в ОС ГЦУСТ. Диспетчеризация ПБ из филиала в филиал супервизором ОУ.. 39

8.15 Решение ПБ аналитиками ЦУС уровней 2 и/или 3 и устранение неисправностей исполнителями.. 39

8.16 Эскалация ПБ супервизорам технической поддержки.. 41

8.17 Общие действия всех подразделений при работе с ПБ.. 42

8.18 Порядок взаимодействия по «глобальным» проблемам.. 44

8.19 Порядок взаимодействия по управлению производительностью сетей телекоммуникаций.. 45

8.20 Отработка ПБ в статусе «Другой ПБ» в рамках одного филиала. 46

8.21 Отработка ПБ между филиалами.. 46

8.22 Правила создания ПБ при проблеме определения локализации источника неисправности.. 47

8.23 Порядок взаимодействия с партнерами Общества. 48

9 Администрирование имен пользователей.. 49

9.1 Администрирование пользователей системы.. 49

9.2 Удаление неиспользованных имен пользователей.. 49

10 Формирование и отработка ВИ в СУПБ.. 50

10.1 Формирование ВИ.. 50

10.2 Ответственные за работу с ВИ.. 50

10.3 Порядок отработки ВИ аналитиками ГЦОУСТ или филиала.. 50

10.4 Рассмотрение в ГЦОУСТ жалоб филиалов по ВИ.. 50

10.5 Описание и алгоритм формирования ВИ.. 52

Приложение А (обязательное) Схемы организации работ в трехуровневой модели TMF.. 58

Приложение Б (обязательное) Описание процесса «Устранение неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком» 59

Приложение В (обязательное) Контрольные сроки и КПР устранения неисправностей ресурсов сетей.. 67

8.8.1. 77

Приложение Г (обязательное) Правила и комментарии по заполнению полей ПБ 81

Г.1 Создание ПБ в СУПБ.. 81

Г.2 Обязательные для заполнения поля. 81

Г.3 Закладки ПБ.. 81

Общие правила выбора кодограмм в ПБ при неисправности объектов. 83

Правила заполнения поля «Зона ответственности» в кодограммах. 84

Правила изменения значения поля «Зона ответственности» в кодограммах. 85

Правила выбора кодограмм при неисправности объектов, 86

находящихся в зоне ответственности ДИС.. 86

Г.3.4 Закладка «История». 91

Г.5 Рекомендации при заполнении полей в ПБ при разных ситуациях: 94

Приложение Д (обязательное) Схема работы с ПБ в филиале и при взаимодействии с супервизорами централизованной поддержки.. 95

Приложение Е (обязательное) Схема работы с ПБ ГЦОУСТ и при взаимодействии между филиалами и ГЦОУСТ.. 96

Приложение Ж (обязательное) Модифицированная структурная схема системы управления аварийными сообщениями сети телекоммуникаций (FM) АО «Казахтелеком». 98

99

Приложение И (обязательное) Значения поля «Категория сети». 100

Аналоговое кабельное TV.. 102

Приложение К (обязательное) Описание отчетов СУПБ.. 105

Приложение Л (обязательное) Нормативные значения показателей Ф.15-2 105

Общие положения

1.1 Настоящий с тандарт организации «Регламент процесса устранения неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком» (Версия 5) (далее – Стандарт) разработан с целью единого подхода к процессу устранения неисправностей ресурсов сетей телекоммуникаций и определяет порядок взаимодействия участников процесса устранения неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком» (далее – Общество).

1.2 Настоящий Стандарт основывается на принципах ролевого управления и разработан:

- в соответствии с Положениями о филиалах Общества, департаментах Центрального аппарата (ЦА);

- на основании формализованного процесса «Управление работами по устранению неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком», утвержденного Приказом от 28.12.2007 года № 535;

- на основании рекомендаций независимой международной организации операторов связи Telecom Management Forum (TMF) в отношении комплектования штата в процессе исходя из трехуровневой модели последовательной специализации персонала;

- в соответствии с Общими требованиями к персоналу Центров управления сетями филиалов АО «Казахтелеком», утвержденными Главным техническим директором от 23.12.2008 № 197;

- с учетом типовых структур Технического блока ЦА и филиалов Общества.

1.3 Организация взаимодействия участников процесса по настоящему Регламенту возлагается на Технических директоров филиалов, курирующих соответствующие подразделения АО «Казахтелеком», а также на Рабочую группу.

1.4 В целях недопущения дублирования информации и, соответственно, увеличения объема работы а налитиков уровня 1 необходимо производить запись всей оперативной информации о неисправностях оборудования сети в СУПБ, руководствуясь пунктом 3.2 Приказ а от 01.09.2009 № 298 « О вводе в промышленную эксплуатацию СУПБ ARS « Remedy ».

 

 

Термины

 

В настоящем Стандарте применяются следующие термины с соответствующими определениями:

2.1 Центр управления сетью (ЦУС): Территориальное объединение подразделений, курируемых общим руководителем (техническим директором) и выполняющих ряд взаимосвязанных функций по управлению сетью, группой клиентов или услуг для определенной географической зоны.

2.2 Пассивное оборудование: Оборудование, не наделенное «интеллектуальными» особенностями (кабельная система, вилка/розетка, повторитель, коммутационная панель, концентратор, монтажные шкафы и стойки, телекоммуникационные шкафы и т.д.).

2.3 Активные ресурсы сетей телекоммуникаций: Ресурсы (активное оборудование, активное сетевое оборудование), которые поддаются удаленному управлению посредством встроенного программного обеспечения.

2.4 Активное оборудование: Электронные, электроннооптические и оптоэлектронные устройства, осуществляющие обработку, коммутацию, формирование и преобразование электрических и/или оптических сигналов, их передачу и получение с использованием дополнительных источников энергии.

2.5 Активное сетевое оборудование: Любое устройство, проводящее цифровую обработку передаваемого сигнала (ЦАТС, коммутаторы, маршрутизаторы, сетевые адаптеры, серверы, модемы).

2.6 Аналитик ЦУС: Работник Общества, выполняющий аналитическую работу по определениюпроблемы, ее устранению или передаче для устранения другому р аботнику Общества. Реальное название этой должности в организации ЦУС может быть другим согласно штатному расписанию подразделения.

2.7 Аналитик ЦУС уровня 1: Владелец проблемы, обеспечивающийкачество обслуживания клиентов и обладающий широкими знаниями в области действующих сервисов и возможных проблем (специалист по сети). В случае невозможности оказания помощи заявителю или решения проблемы собственными силами передает проблему аналитикам уровней 2 или 3. Является первым контактным лицом при наступлении события.

2.8 Аналитик ЦУС уровня 2: Управляющий проблемой, специализирующийся в нескольких видах сервиса. Не обладая такими же широкими знаниями, как аналитик ЦУС уровня 1, является экспертом по поддерживаемым сервисам. Если проблема является системной, то передает управление проблемой системному инженеру.

2.9 Аналитик ЦУС уровня 3: Управляющий проблемой, системный специалист (системный инженер), обладает глубокими знаниями в области одной или нескольких систем, являющихся частью клиентского сервиса.

2.10 Исполнитель: Работник Общества, инженер по сетевому элементу, непосредственно обслуживающий участок сети и не являющийся аналитиком ЦУС.

2.11 Аналитик по мониторингу производительности сети: Работник Общества, принимающий участие в процессе управления качеством работы сетей телекоммуникаций, выполняет функции мониторинга производительности сети, анализа проблемных билетов, связанных с изменениями качественных характеристик сети.

2.12 Супервизор ОУ: Работник Общества, осуществляющий координацию деятельности аналитиков ЦУС, соответствующих подразделений, выполняющий эскалацию проблем на другой уровень и обеспечивающий решение глобальных проблем.

2.13 Супервизор ТП: Работник Общества, осуществляющий координацию работ по технической поддержке деятельности подразделений и выполняющий функции по взаимодействию с фирменной сервисной поддержкой от лица АО «Казахтелеком».

2.14 Проблемный билет (ПБ): Электронный документ в видеучетной записи базы данных ARS Remedy, описывающий проблему и историю действий по ее решению.

2.15 Инициатор ПБ: Работник Общества или внешнее приложение, инициировавшие, вручную или автоматически, создание в системе нового ПБ.

2.16 Диспетчеризация ПБ: Перевод заявки (проблемного билета) от регистратора к исполнителю для решения проблемы.

2.17 Эскалация заявки/проблемного билета: Процедура повышения статуса и расширения зоны действия заявки/проблемного билета и вовлечения дополнительных человеческих ресурсов.

2.18 Рабочая группа (РГ): Группа квалифицированных работников Общества по унификации и совершенствованию технологического процесса «Управление работами по устранению неисправностей ресурсов сетей телекоммуникаций» в целом по Обществу.

2.19 Инцидент: Любое событие, не являющееся частью нормального функционирования процесса и при этом влияющее или способное оказать влияние на снижение качества сервиса или полное прекращение его предоставления.

2.20 Внутренний инцидент: Событие, создающееся по фактам некорректной работы персонала в технологическом процессе.

2.21 Объект мониторинга: Сетевой элемент филиала (активное сетевое оборудование), являющийся объектом мониторинга для соответствующей системы управления NFM (Netcool, IRISnGEN).

2.22 Основной ПБ: ПБ, созданный по событию, являющемуся корневой причиной какой-либо аварийной ситуации на сети, имеющий связь с группой ПБ, созданных по симптомным событиям.

2.23 Другой ПБ (подбилет): ПБ, созданный по симптомному событию, являющем у ся следствием корневой причины проблемы, для которой уже создан основной ПБ в рамках одного филиала.

2.24 Межфилиальный ПБ: ПБ, созданный подразделением, не в зоне контроля которого возникла неисправность, и являющийся следствием корневой причины, для которой создан «Корневой ПБ».

2.25 Корневая проблема: Событие об изменении состояния сети, услуги или сервисов, в результате которого возникают проблемы с предоставлением услуг/сервисов у двух и более филиалов.

2.26 Глобальная проблема: Событие об изменении состояния сети, услуги или сервисов, в результате которого возникают проблемы с предоставлением услуг/сервисов на сети Общества.

2.27 Модуль ремонтооборота (РО): Модуль – электронный портал, отражающий функционирование процесса ремонтооборота (дочернего процесса – техподдержки), вид учетной записи базы данных ARS Remedy, описывающей проблему, имеющую решение в виде ремонта / замены части (или целого) активного сетевого оборудования и историю действий по ее решению.

2.28 РНР: Ремонтн о-н астроечные работы, процесс оформления и согласования которых автоматизирован в СУЗТОРС(система учета заявок на техническое обслуживание ресурсов сети).

2.29 Высокоприоритетные ПБ: ПБ, созданные по событиям, поступившим от оборудования, поле «Категория сети» у которых имеет одно из важных значений.

2.30 Партнер: Юридическое лицо, являющееся одним из участников процесса устранения неисправностей оборудования Общества.

2.31 Куратор группы супервизоров: Старший определенной группы супервизоров, получающий оповещения системы о действиях,просроченных его подчиненными, с целью дальнейшей координации действий.

2.32 Важные значения поля «Категория сети» (полное описание см. в п. «Категория сети» п риложени я И к Стандарту).

 

 

Cокращения

 

 

В настоящем Стандарте применяются следующие сокращения:

ЦА – Центральный аппарат;

ГЦУСТ – Главный центр управления сетями телекоммуникаций – филиал АО «Казахтелеком»;

ДГЦОУСТ ГЦУСТ – Департамент « Главный центр оперативного управления сетями телекоммуникаций » ГЦУСТ;

ДЦТЭ ГЦУСТ –Департамент « Центр технической эксплуатации » ГЦУСТ;

ОС ГЦУСТ – объединенная с мена ГЦУСТ, функциональная группа (ГЦОУСТ,ОДС,ЦКС ГЦУСТ, ПД ГЦУСТ), выполняющая роль Центра оперативного управления АО «Казахтелеком»;

ЦТЭяСПД – Центр технической эксплуатации ядра сети передачи данных;

ДУТП – Департамент управления технологическими процессами;

СУПБ (ARS Remedy) – система управления проблемными билетами;

СУСТ – система управления сетями телекоммуникаций;

ПБ – проблемный билет;

ЦОУ – Центр оперативного управления;

СЭиРСТ – Служба эксплуатации и развития сетей телекоммуникаций;

СОПС – система обработки потоков сообщений;

СОЭАС – система обогащения и эскалации аварийных сообщений;

ДКП – Дирекция корпоративных продаж;

ДИС – Дирекция информационных систем;

ОДС – Объединение «Дальняя связь»;

ГЦТ – городской центр телекоммуникаций;

ОДТ – областная дирекция телекоммуникаций;

Филиал – подразделение АО «Казахтелеком», не входящее в ЦА;

СЦ – сервис-центр;

ЦТЭ – Центр технической эксплуатации филиала;

ГОЗ – график обходов и замен;

СП – система передачи;

ЦТ– цифровой тракт;

АЦП – аналого-цифровой преобразователь;

БД – база данных;

ПО – программноеобеспечение;

КРП – кратковременные пропадания связи;

КПР – ключевой показатель результативности;

KPI - Key Performance Indicators;

ВИ – внутренний инцидент;

ТБ – Технический блок;

РГП – Республиканское государственное предприятие;

TMF (Telecom Management Forum) – международная организация по управлению телекоммуникациями;

NFM (Network Fault Management) – система управления отказами;

EMS (Element Management Systems) – система управления элементами (сети);

NMS (Network Management Systems) – система управления сетью;

ПБc – ПБ сервиса;

ПБр – ПБ ресурса.

 

 

Рисунок 1 – Схема перехода статусов проблемного билета (ПБ)

 

В Таблице 2 описаны статусы ПБ.

 

Таблица 2 – Статусы ПБ

Статус ПБ	Описание статуса	Комментарии
Новый	Билет создан вручную или автоматически и направлен исполнителю	Начальный статус ПБ
Назначен	Исполнитель подтвердил принятие ПБ	Промежуточный статус ПБ
В работе	Исполнитель назначен на месте	Промежуточный статус ПБ

Таблица 2 – Статусы ПБ (продолжение)

 

Статус ПБ	Описание статуса	Комментарии
Отложен	Проблема не может быть решена без помощи централизованной техподдержки или производителя оборудования. Вложенный в ПБ аварийный рапорт может быть направлен в СЦ производителя	Промежуточный статус ПБ. При переводе в статус «Отложен» контрольный срок решения ПБ определяется контрактом на техподдержку
Решен	Исполнитель считает проблему решенной	Промежуточный статус ПБ. Статус, при переводе ПБ в который определяется фактическое время устранения неисправности
Отвергнут	Исполнитель обнаружил, что неисправность вызвана причиной, отличной от описанной в ПБ, или ПБ должен быть передан другому исполнителю	Промежуточный статус ПБ
Отменен	ПБ не будет дальше решаться по какой-либо причине. Выполнение действия "Отменить ПБ" разрешается только группе владельцев ПБ	Конечный статус ПБ
Другой ПБ	Проблема уже описана в другом ПБ и не рассматривается далее в рамках данного ПБ	Конечный статус ПБ
Закрыт	ПБ закрыт. Выполнение действия "Закрыть ПБ" разрешается только группе владельцев ПБ	Конечный статус ПБ
Эскалирован	Проблема не может быть решена без помощи супервизора ТП. Вложенный в ПБ аварийный рапорт направлен в подразделение централизованной техподдержки	Промежуточный статус ПБ. Статус, при котором супервизор ТП может выполнить одно из действий: 1. «Вернуть эскалированный ПБ». Данным действием супервизор ТП сообщает филиалу о необходимости внести в ПБ недостающую информациюлибо подкорректировать имеющуюся. После выполнения действия ПБ переходит обратно в статус «В работе»; 2. «Перенести решение ПБ супервизору». Данным действием супервизор ТП сообщает, что начинает работу с ПБ (самостоятельно, либо с помощью специалистов сервис-центра производителя). После выполнения действия ПБ переходит в статус «Отложен»; 3. «Передача ПБ другой группе супервизоров». Данным действием супервизор ТП передает ответственность за решение ПБ другой группе супервизоров ТП. После выполнения действия ПБ остается в статусе «Эскалирован»
Развитие	ПБ в статус «Развитие» переводится действием «Перевести в статус Развитие» аналитиками ГЦОУСТ в тех случаях, когда филиалу требуется реализовать новую функциональность и/или услугу т.е. возникает необходимость разработки нового ПО или проведения закупа дополнительного оборудования. При этом указанные вопросы не могут быть решены в рамках ТП, и как следствие требуется разработать новый проект и определить источники финансирования. Такие ПБ не должны оказывать влияние или приводить к влиянию на коммерческие сервисы кампании.	Промежуточный статус ПБ. В этот статус ПБ переводится после выполнения действий «Эскалировать ПБ в группу ГЦОУСТ Развитие» и «Перевести в статус Развитие»

 

 

В случае необходимости продления контрольного срока (до его окончания) к ПБ должны быть приложены подтверждающие документы, в поле «Ход работы» необходимо внести соответствующую запись и выполнить действие «Эскалировать ПБ в группу «Развитие» ГЦОУСТ».

 

8.11.8 При возникновении аварийной ситуации, по проблеме, описанной в имеющемся ПБ в статусе "Развитие", филиал обязан открыть новый ПБ, в котором должны быть зафиксированы все статусы объекта ("1" -Авария, "2" - Повреждение, "11" - КРП). Данные ПБ запрещено "прикреплять" к ПБ в статусе "Развитие".

Как в имеющемся ПБ в статусе "Развитие", так и в новом ПБ должна быть внесена запись, указывающая на существование другого ПБ:

- в «Текущем ходе» ПБ в статусе "Развитие" должен быть указан номер каждого нового ПБ, возникающего по имеющейся проблеме, с указанием времени и кодограмм, зафиксированных в каждом новом ПБ;

- в «Текущем ходе» каждого нового ПБ, должен быть указан номер существующего ПБ в статусе "Развитие".

 

Рисунок 2 – Схема привязки подбилета к основному ПБ в пределах одного филиала

 

Формирование ВИ

 

Внутренние инциденты (ВИ) формируются при выявлении некорректной работы персонала в процессе устранения неисправностей ресурсов сети. ВИ формируются автоматически системой в процессе работы пользователей с ПБ либо вручную в процессе анализа информационных полей ПБ, проводимого ответственными работниками ГЦУСТ.

 

Таблица 3 – Описание и алгоритм формирования

№	Тип внутреннего инцидента	Описание	Алгоритм формирования	Ответственный за анализ ВИ
	Неоднократная передача ПБ между филиалами	В ПБ встречается неотмененное действие «Переслать ПБ в ГЦУ» более трех раз	Автоматически, в случае,если происходила передача ПБ из одного филиала в другой действием «Переслать ПБ в ГЦУ» более трех раз.   Формируются ВИ только для закрытых ПБ (Статус «Закрыт»). Сформированный ВИ соотносится с филиалом, указанным в поле ПБ «Зона ответственности». Если количество действий пользователя превышает пороговое, но не совпадают значение поля ПБ «Зона ответственности» и филиал пользователя, выполнявшего действие, то ВИ формироваться не должен	Аналитик ГЦОУСТ
	Неоднократная передача ПБ супервизору	В ПБ встречается неотмененное действие «Эскалировать ПБ супервизору» после действия «Вернуть эскалированный ПБ» и более трех раз	Автоматически, в случае, если выполнялось действие «Эскалировать ПБ супервизору» после действия «Вернуть эскалированный ПБ» и более трех раз	Филиал

Таблица 3 – Описание и алгоритм формирования (продолжение)

 

№	Тип внутреннего инцидента	Описание	Алгоритм формирования	Ответственный за анализ ВИ
	Неоднократная передача ПБ внутри филиала	В ПБ встречается не отмененное действие «Отвергнуть» более одного раза пользователями одного и того же филиала	Автоматически, в случае, если ПБ был отвергнут каким-либо исполнителем филиала более одного раза действием «Отвергнуть». Формируются ВИ только для закрытых ПБ (статус «Закрыт»). Сформированный ВИ соотносится с филиалом, указанным в поле ПБ «Зона ответственности». Если количество действий пользователя превышает пороговое, но не совпадают значение поля ПБ «Зона ответственности» и филиал пользователя, выполнявшего действие, то ВИ формироваться не должен	Филиал

 

Некорректно заполнено поле «Итоговое заключение»

Значение поля «Итоговое заключение» имеет отличный от заключения о проведенных работах смысл. Например: значение равно пробелам или другим подобным символам, не несущим какую-либо смысловую нагрузку

Вручную, методом анализа заполнения полей ПБ

Аналитик ГЦОУСТ

Таблица 3 – Описание и алгоритм формирования (продолжение)

 

	Некорректная запись в журнале «Ход работы»	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ
	Некорректно указан «Характер повреждения»	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ
	Некорректно указана «Зона ответственности»	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ
	Некорректно указана «Категория сети»	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ
	Некорректно указано «Время возникновения аварии»	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ
	Некорректно указано «Подробное описание аварии»	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ

Таблица 3 – Описание и алгоритм формирования (продолжение)

 

	Некорректно указаны дата и время устранения инцидента	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ
	Некорректные записи в таблице «Состояния неисправности»	Поле имеет некорректное значение	Вручную, методом анализа заполнения полей ПБ	Аналитик ГЦОУСТ
	Контроль своевременного информирования ЦОУ о возникновении аварийной ситуации	Задействованы только ПБ, созданные в ручном режиме, у которых время реагирования имеет значение большее, чем «Пороговое значение»	Автоматически, в случае, если ПБ соответствует следующим условиям: «первое значение состояния неисправности равно «1 – авария».   Поле «Категория сети» имеет важные значения.   Время реагирования в ПБ рассчитывается как разность между значениями полей «Время регистрации ПБ» и «Время возникновения аварии» и где значение разности превышает пороговое значение = 16 минут	Филиал

 

 

Приложение А
(обязательное)
Схемы организации работ в трехуровневой модели TMF

 

Рисунок А.1 – Трехуровневая модель последовательной специализации персонала в процессе «Управление работами по устранению неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком»

Приложение Б
(обязательное)
Описание процесса «Устранение неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком»

 

Рисунок Б.1 – Модель процесса «Управление работами по устранению неисправностей ресурсов сетей телекоммуникаций АО «Казахтелеком»

Таблица В.1 – Базовые контрольные сроки и принципы расчета

 

Уровень	Значениие поля СУПБ «Характер повреждения»	Формула расчета порогового значения контрольного срока	Методика расчета
Уровень «Критический»	Станционное	60 минут	– Учитываются все ПБ, для которых имеется хоть одно значение «1–авария» поля «Код неисправности» таблицы «Состояние неисправности». –Длительность устранения неисправности рассчитывается как разность между значениями даты/времени ввода кода «1» поля «Код неисправности» таблицы «Состояние неисправности» и любым другим кодом, введенным следующим после «1» в хронологическом порядке. В случае, если в таблице «Состояние неисправности» отсутствует следующий код после кода «1», то разность рассчитывается между значениями даты/времени последнего ввода кода «1» и датой/временем устранения инцидента. Все полученные разности суммируются. Итоговая сумма сравнивается с контрольным сроком для критических событий, указанным в ПБ
Линейное	360 минут + time_way
Терминальное оборудование	72 часа
Уровень «Срочный»	Станционное	1440 минут[26]	Учитываются все ПБ, для которых имеется хоть одно значение «1–авария» или «2–повреждение» поля «Код неисправности» таблицы «Состояние неисправности». Длительность устранения неисправности рассчитывается как разность между значениями даты/времени ввода кода «1» или «2» и следующим после указанных в хронологическом порядке. В случае, если в таблице «Состояние неисправности» отсутствует следующий код после кода «1» или «2», то разность рассчитывается между значениями даты/времени последнего ввода кода «1» или «2» и датой/временем устранения инцидента. Все полученные разности суммируются. Итоговая сумма сравнивается с контрольным сроком для срочных событий, указанным в ПБ
Линейное	1440 минут + time_way
	Терминальное оборудование	72 часа
Уровень «Несрочный»	Станционное	14400 минут[27]	– Учитываются все ПБ, для которых имеется хоть одно значение «1–авария», «2–повреждение» или «2б–предупреждение» поля «Код неисправности» таблицы «Состояние неисправности». – Длительность устранения неисправности рассчитывается как разность между значениями даты/времени ввода кодов «1», «2» или «2б» и следущим после указанных в хронологическом порядке. В случае, если в таблице «Состояние неисправности» отсутствует следующий код после кода «1», «2» или «2б», то разность рассчитывается между значениями даты/времени последнего ввода кода «1», «2» или «2б» и датой/временем устранения инцидента. Все полученные разности суммируются. Итоговая сумма сравнивается с контрольным сроком для срочных событий, указанным в ПБ
Линейное	14400 минут + time_way
Терминальное оборудование	72 часа

 

Данные правила применяются как для ПБ, созданных в автоматическом режиме, так и для ПБ, созданных вручную.

При каждом изменении значений поля «Характер повреждения» все три пороговые значения контрольных сроков должны быть перерасчитаны по соответствующим формулам. Для ПБ, созданных вручную, перерасчет осуществляется, если указано наименование объекта из справочника СУСТ. Если объект не указан, то по умолчанию остаются регламентированные значения контрольных сроков для каждого из уровней. Перерасчет не производится, если в поле «Категория сети» установлено значение «Сеть доступа» (см. ниже пункт «Формирование ПБ по неисправностям ЛКС»).