Отчет по практике на "Евраз объединенный ЗСМК"

Автор: Пользователь скрыл имя, 19 Октября 2012 в 16:06, отчет по практике

Описание работы

«ЕВРАЗ ОБЪЕДИНЕННЫЙ ЗСМК» - предприятие вертикально-интегрированной горно-металлургической компании «Евраз Груп С.А.» (Evraz Group S.A.), входящей в число пятнадцати лидеров мировой сталелитейной отрасли. Комбинат образован 5 мая 2003 г. на базе производственных мощностей легендарного КМК, более семидесяти лет поставлявшего свою продукцию в разные уголки России и за рубеж.

Содержание

1. Общие сведения о предприятии
1.1. История
1.2. Рыночные позиции «ЕВРАЗ ОБЪЕДИНЕННЫЙ ЗСМК»
1.3. Краткая характеристика структуры «ЕВРАЗ ОБЪЕДИНЕННЫЙ ЗСМК»
2. Организационная структура Управления Информационных Технологий
3. Применяемое на «ЕВРАЗ ОБЪЕДИНЕННЫЙ ЗСМК» техническое и программное обеспечение
4. Service Desk
4.1. Системы Service Desk
4.2. Методология организации службы
4.3. Цели и результаты внедрения Service Desk-системы на «ЕВРАЗ ОБЪЕДИНЕННЫЙ ЗСМК»
5.Процесс управления инцидентами
5.1. Термины и определения
5.2. Обозначения и сокращения
5.3. Цели и политика процесса управления инцидентами
5.4. Описание процесса управления инцидентами
Приложения

Работа содержит 1 файл

Отчет SD3.docx

— 1.91 Мб (Скачать)
        1. Менеджер процесса имеет право закрыть заявку собственным решением.
      1. Основные правила диспетчеризации «Инцидентов (автоматических)»:
        1. регистрация инцидента осуществляется автоматически системой мониторинга;
        2. логистика инцидента определяет Конфигурационная единица, по которой произошел инцидент;
        3. Инциденты закрываются либо руководителем исполнителя, либо исполнителем.
      2. Для быстрой обработки Инцидентов могут использоваться обходные решения.
      3. Инциденты, к которым применено обходное решение, будут требовать дополнительного контроля:
        1. Возникновение инцидента с неизвестной корневой причиной или повторяющиеся инциденты служат для инициации процесса управления Проблемами.
        2. Изменения, требуемые для устранения корневых причин инцидента, происходят согласно процессу управления Изменениями.
      4. Информация о состоянии заявки (Статус) доступна Заявителю на протяжении всего жизненного цикла заявки. Запрос статуса обращения регистрируется как отдельная заявка.
      5. За контроль соблюдения технологии процесса отвечает Менеджер процесса.
      6. Показатели качества (метрики) работы собираются с целью:
        1. оценки качества работы подразделений ИТ-службы и систем;
        2. регулярного совершенствования процесса управления.
        3. отчётности по соглашениям SLA.
      7. Хорошие навыки общения являются обязательным требованием к Диспетчерам ЕСПП и должны быть регламентированы специальным документом.

 

  1. Описание процесса управления инцидентами.
    1.    Общее положение
      1. Диаграмма процесса управления инцидентами представлена на рис.1. Процесс управления инцидентами состоит из нескольких процедур. Каждая процедура состоит из нескольких шагов. Для идентификации составляющих процесса применяется каскадная нумерация: процесс управления инцидентами имеет порядковый номер 1, процедуры нумеруются как 1.1., 1.2. и т.д., шаги – как 1.1.1., 1.1.2. и т.д. Процесс управления инцидентами содержит следующие процедуры:

- 1.1. Обращение  в ЕСПП;

- 1.2. Регистрация  и первичная классификация;

- 1.3. Координация  и устранение;

- 1.4. Закрытие;

- 1.5. Контроль;

- 1.6. Формирование  отчётности;

- 1.7. Оценка  и совершенствование процесса.

 Рисунок 1 – Диаграмма процесса «Управления Инцидентами»

      1. Автоматизацию процесса управления инцидентами обеспечивает Автоматизированная система управления HP OpenView.
    1.    Обращение в ЕСПП
      1. На рис.2 представлена диаграмма обращения в ЕСПП.

 Рисунок 2 – Диаграмма «Обращение в ЕСПП»

      1. При обращении в ЕСПП Пользователь должен идентифицировать себя (ФИО, должность, предприятие, телефон и т.д.), сообщить суть обращения, предоставить дополнительную информацию (если имеется).
    1.    Регистрация и первичная классификация
      1. На рис.3 представлена диаграмма регистрации и первичной классификации заявок.

Рисунок 3 – Диаграмма «Регистрация и первичная классификация

      1. Определение приоритета.
        1. Диспетчер определяет критичность заявки (приоритет) и масштаб инцидента (влияние) со слов заявителя. При принятии заявки специалист должен актуализировать данные поля.
        2. Влияние зависит от количества сотрудников, на которых влияет данный сбой, и может иметь следующие значения:

- Низкое  – отдельный пользователь;

- Среднее  – два-три пользователя;

- Высокое  – группа;

- Высшее  – организация.

        1. Поле «Приоритет» зависит от поля «Влияние» и срочности заявки согласно матрице приоритета (таблица 1). При выставлении значения поля «Влияния» на «Высокое» изменится и приоритет заявки на «Высокий». Допускается выставление приоритета «Высокий» при низком влиянии, если неисполнение данной заявки приведет к негативным последствиям для бизнес или производственных процессов.
        2. Для определения влияния и срочности допускается использовать дополнительные сопроводительные документы. Пример документа приведен в Приложении 1.
        3. Приоритеты оцениваются следующими значениями:

– Низкий;

– Средний;

– Высокий;

– Критичный.

 

                  Таблица 1. Матрица приоритета

   

Инцидент влияет на

   

Организация

Группа

Отдельный пользователь

Срочность

Высокая

Критичный

Критичный

Высокий

Средняя

Критичный

Высокий

Средний

Низкая

Высокий

Средний

Низкий


 

        1. Диспетчер или Менеджер процесса (при регистрации или в течение всего жизненного цикла Заявки) могут повысить приоритет Заявки. Понижение Приоритета запрещено, за исключением ошибки при выборе приоритета.
    1.    Координация и устранение
      1. Диаграмма по координации и устранению представлена на рис.4.

 Рисунок 4 – Диаграмма «Координация и устранение»

    1.    Закрытие
      1. На рис.5 представлена диаграмма закрытия.

Рисунок 5 – Диаграмма «Закрытие»

    1.    Контроль
      1. В рамках процедуры проводятся мероприятия по оперативному контролю исполнения процесса и могут быть инициированы действия по эскалации, закрытию выполненных Заявок, диспетчеризации, выяснению нестандартных ситуаций.
      2. Кроме перечисленных процедур контроль осуществляется Руководителем группы и Исполнителем в соответствии с процессом Управления работами.
      3. Для выявления корневых причин инцидента, оценки потерь, понесенных в результате возникновения инцидента, может инициироваться процедура проведения технического расследования инцидента:
        1. Для инцидентов с влиянием  «Критично» – во всех случаях, для инцидентов с влиянием  «Высокий» - по решению Вице-президента по ИТ или директор по эксплуатации или директора по ИТ предприятия.
        2. Для проведения технического расследования создается комиссия из числа сотрудников дирекции по ИТ соответствующего предприятия,  а также  организации предоставляющий ИТ- сервис
        3. К участию в  работе комиссии могут приглашаться сотрудники функциональных подразделений – заказчиков и потребителей данного ИТ- сервиса, а так же представители других заинтересованных подразделений
        4. По результатам работы комиссии готовится «Акт технического расследования причин инцидента» содержащий: описание инцидента, его последствий, действия по устранению, заключения о причинах инцидента и мероприятиях по предотвращению подобных инцидентов в будущем. Шаблон акта приведен в Приложении 2.
    2.    Формирование отчётности
      1. Описание шагов процедуры:

■ 1.6. Формирование отчетности;

■ 1.6.1. Разработка Спецификаций отчетов;

■ 1.6.2. Подготовка отчетов;

■ 1.6.3. Распространение отчетов.

      1. В рамках процедуры осуществляется спецификация отчетов, а также их подготовка, распространение и хранение. Отчёты могут быть двух видов:

- регулярные;

- специализированные.

      1. Спецификация каждого отчёта должна включать:
        1. Название отчёта;
        2. Перечень используемых показателей;
        3. Формат (внешний вид) отчета;
        4. Периодичность формирования;
        5. Список и способ рассылки;
      2. Спецификации отчётов готовят Главный Менеджер процесса, Менеджеры процессов.
      3. Все подготовленные отчёты должны унифицированно именоваться, храниться и распространяться.
      4. Менеджер процесса готовит следующие регулярные отчёты:
        1. Базовый ежедневный отчет;
        2. Базовый еженедельный отчет;
        3. Ежемесячный аналитический отчет;
      5. Базовый ежедневный (еженедельный) отчет
        1. основные показатели:

- количество  зарегистрированных Заявок;

- разбивка  по категории Заявок;

- количество  нарушений SLA;

        1. перечень нестандартных ситуаций, например:

- данные  о жалобах, благодарностях;

- данные  о критических инцидентах.

        1. По форме отчет должен содержать перечень показателей и их значений, табличное представление нестандартных ситуаций с необходимыми комментариями. Допускается графическое представление сложных показателей.
        2. Отчеты должен готовиться ежедневно (еженедельно) и передаваться соответствующим руководителям в бумажном или электронном виде. Примеры отчетов приведены в Приложении 3.
      1. Ежемесячный аналитический отчёт о работе процесса
        1. Отчет включает анализ основных показателей процесса в целом (включая показатели удовлетворённости пользователей), показателей отдельных процедур процесса, их динамики.
        2. Отчет должен включать выводы и рекомендации. Отчет готовится ежемесячно и передается в бумажном или электронном виде. Аналитический отчёт в обязательном порядке сопровождается личным докладом.
    1.    Оценка и совершенствование процесса
      1. На рис.6 представлена диаграмма оценки и совершенствования процесса.

Рисунок 6 – Диаграмма «Оценка  и совершенствование процесса»

      1. Описание шагов процедуры:
        • 1.7. Оценка и совершенствование процесса;
        • 1.7.1. Оценка и пересмотр процесса на предмет его улучшения;
        • 1.7.2. Действия по результатам пересмотра процесса;
        • 1.7.3. Проверка исполнения предпринятых действий.
      1. Основная задача данной процедуры — определение путей совершенствования процесса управления инцидентами и его адаптация под происходящие в организации изменения.
      1. Каждые 6 месяцев (или по требованию) процессу Управления Инцидентами должна быть дана оценка.
      2. Исходные данные:
        1. описание процесса Управления Инцидентами;
        2. отзывы Пользователей;
        3. отзывы Исполнителей и Администраторов;
        4. отзывы Руководителей групп;
        5. показатели процесса и процедур;
        6. зарегистрированные в системе Заявки и Работы;
        7. стандартные отчёты.
      3. Анализ процесса проводится Главным технологом процесса с привлечением Менеджеров процессов в ходе серии рабочих совещаний.
      4. Результат – отчёт о работе процесса, включающий рекомендации по улучшению процесса.
      5. Подготовленные рекомендации утверждает соответствующим руководителем.
      6. Контроль исполнения рекомендаций по совершенствованию процесса возлагается на Главного менеджера процесс

 

 

 

 

Приложение 1

 

Таблица А1. Сроки отчетности для  определения критичности заявок

Сервис

Срок отчетного периода

2.1.7.

Учет расчетов с контрагентами

с 3 по 15 м-ца, следующего за отчетным периодом

2.1.4.

Планирование и учет производства

c 30 по 03 число месяца, следующего  за отчетным

3.6.2.

Расчет заработной платы

1-7 число месяца

2.1.3.

Снабжение и управление запасами

с 2 по 6 , следующего за отчетным периодом

2.1.6.

Управление сбытом продукции и  услуг – SAP

с 1 по 4 , следующего за отчетным периодом

3.11.2.

Управление сбытом продукции и  услуг – ДС

с 1 по 4 , следующего за отчетным периодом

2.1.4.

Контроллинг

c 01 по 09 число месяца, следующего  за отчетным

2.1.7.

Учет основных средств

с 1 по 8 м-ца, следующего за отчетным периодом

2.1.10.

Управление инвестиционными проектами

с 1 по 8 м-ца, следующего за отчетным периодом

2.1.7.

Бухгалтерский и налоговый учет

с 3 по 15 м-ца, следующего за отчетным периодом

2.1.7.

Финансовый менеджмент

с 1 по 6 м-ца, следующего за отчетным периодом

2.1.5.

Техническое обслуживание и ремонт оборудования

c 01 по 09 число месяца, следующего  за отчетным

3.8.2.

Управление деятельностью УЖДТ

с 1 по 5 числа месяца

4.29.2.

Управление деятельностью механического  производства

3 последних дня месяца и 5 первых в следующем

3.9.2.

Отпуск ГСМ на АЗС

1 число месяца

3.9.2.

Управление эксплуатацией и  ремонтом автотранспорта

с 1 по 3 число месяца

3.8.2.

ЖД Перевозки

с 1 по 31

3.8.2.

ЭТРАН

с 1 по 31

3.6.2.

Персонифицированный учет

Высокий приоритет только при формировании годового отчета в налоговые органы (январь)

3.6.2.

Ведение участников негосударственного пенсионного фонда

Высокий приоритет только при формировании годового отчета в налоговые органы (февраль)

3.8.2.

Претензионная работа с РЖД

с 5 по 7 , следующего за отчетным периодом

3.8.2.

Расчеты за перевозки с РЖД

с 5 по 7 , следующего за отчетным периодом

2.2.2.

ОАО «Евразруда»:  система 1С «Заработная  плата и кадры»    

с 01 по 04

2.2.4.

ОАО «Евразруда»:  система 1С           Закрытие участков учета в системе ИРТП ПРОФ

с 03 по 11

2.2.4.

ОАО «Евразруда»:  система 1С ЕКСП       

 с 01 по 10.

Информация о работе Отчет по практике на "Евраз объединенный ЗСМК"