Инструменты IT-департаментов больших компаний: как избавляться от хаоса и считать каждую копейку

 

Форма заявкиПредставьте, что вы приходите в большую компанию руководить ИТ-департаментом, и понимаете, что там просто конь не валялся. В самом простом случае у вас есть от 50 человек, куча бумажек про закупки и перемещения, инвентарная опись оборудования… и, пожалуй, всё.Первая задача, с которой начинается разбор хаоса — это аудит подразделений/процессов и работа с самыми важными и тормозящими. Хочется точно знать, как решаются сбои — заводится система тикетов-инцидентов… Хочется автоматизировать большую часть задач — система тикетов обрастает функционалом бизнес-правил. Хочется, чтобы пользователи разгрузили саппорт — и вот уже у них есть свои инструменты для формирования заявок, причём такие, что отправить заявку, не заполнив все нужные данные, просто нельзя.

Управление уровнем ИТ-услуг. Часть 2. Каталог ИТ-услуг и процессы

Все должно быть сделано настолько просто,
насколько это возможно. Но не проще.

Альберт Эйнштейн

В первой части статьи мы договорились о терминологии, а также обсудили преимущества от внедрения сервисного подхода и трудности реализации на примере внутреннего ИТ-подразделения, оказывающего услуги своей компании. В этой статье мы сформулируем и обсудим структурный подход к проектированию каталога ИТ-услуг и процесса управления уровнем ИТ-услуг.

Определение целей проекта

Первый и главный шаг при подготовке проекта по организации управления уровнем ИТ-услуг — определение целей. Разумно отталкиваться от списка преимуществ, которые могут быть достигнуты за счет организации сервисного подхода (см. первую часть статьи), дополняя и детализируя их там, где необходимо. Банальная, но от того не менее полезная рекомендация — определить ключевые группы заинтересованных лиц и связать задачи проекта с их интересами. Например, может получиться так, что бизнесу управление уровнем ИТ-услуг прежде всего интересно как основа для численного измерения и контроля деятельности ИТ-подразделения, а ИТ-руководству важно перейти к экономически обоснованному управлению ИТ. Четко сформулированные цели проекта в контексте заинтересованных сторон будут полезны на протяжении всего проекта и могут оказывать существенное влияние на принимаемые процессные решения.

Управление уровнем ИТ-услуг. Часть 1. Высокие отношения

С фактами не спорят.
Их объясняют.

Василий Гроссман

В последние два-три года мы, сотрудники компании Cleverics, отмечаем стабильное повышение интереса к теме управления уровнем ИТ-услуг.Это касается и слушателей семинаров, и клиентов консалтинговой практики. Вопросы, которые интересуют наших клиентов, кратко можно сформулировать так: «Что такое ИТ-услуги и в чем заключаются сервисные отношения?», «Как построить каталог услуг?», «Как организовать процесс управления уровнем ИТ-услуг?», и «Как не превратить управление уровнем ИТ-услуг в бессмысленную бюрократию и извлечь максимум пользы?».

Данная статья начинает цикл публикаций про управление уровнем ИТ-услуг, в рамках которых мы постараемся системно и как можно более конкретно ответить на перечисленные вопросы, опираясь не только на общедоступные издания, но и на наш проектный опыт. И конечно начнем мы с вопроса «Что такое ИТ-услуги и в чем заключаются сервисные отношения?».

Говорим на одном языке

Что такое ИТ-услуга

Книги библиотеки ITIL, начиная с версии 3 (май 2007 года) содержат великолепное определение:

Наводим мосты

Слишком много людей думает о защите

вместо того, чтобы думать о возможности.

Бенджамин Франклин

Автор: Дмитрий Исайченко

Несмотря на обилие материалов и по разработке, и по эксплуатации информационных систем, организация эффективного взаимодействия подразделений разработки и эксплуатации является одним из наиболее актуальных вопросов для ИТ-руководителей. О типичных проблемах в этой области и о практике их решения мы и поговорим в данной статье.

Предмет анализа

Начнем с определения организационного контекста, который поможет нам более четко сформулировать задачу. Для этого представим обычную ИТ-организацию, имеющую функциональную организационную структуру и применяющую не только готовые коммерческие продукты, но также активно использующую внутреннюю разработку. В этом случае в данной организации можно выделить два крупных функциональных блока — департаменты разработки и эксплуатации (Рисунок 1).

Департамент разработки отвечает за развитие информационных систем и обрабатывает запросы на разработку от бизнес-руководителей или выделенных сотрудников (обычно здесь также присутствуют функции управления проектами, закупками и архитектурой, вовлеченные в проекты внедрения новых информационных систем, но в данной статье мы без этих функций можем обойтись). В своей деятельности департамент разработки в основном руководствуется подходом ALM (Application Lifecycle Management) и возможно даже использует соответствующее специализированное программное обеспечение для управления требованиями, распределения задач на разработку, определения содержания релизов, организации тестирования, отслеживания дефектов и прочего.

Выбор система регистрации обращения

Продукты

1. HP OpenView Service Desk

2. BMC Remedy Service Desk

3. IBM Tivoli Service Desk

4. Microsoft System center

5. Naumen Service Desk

Описание

HP OpenView Service Desk

разрабатывался специально с учетом требований крупных компаний и их подразделений, ответственных за работу информационной инфраструктуры и предоставление информационных сервисов пользователям. Приложение поддерживает все процедуры назначения, контроля, документирования информационных услуг, предоставляемых пользователям. Базируясь на рекомендациях ITIL — Information Technology Infrastructure Library, HP OpenView Service Desk поддерживает следующие процедуры и функции:

• управление обращениями пользователей (Service desk);
• управление инцидентами (Incident management);

Процедура приёма новых систем на поддержку

СОДЕРЖАНИЕ

 

Название процедуры.. 2

Код. 2

Цель документа. 2

Модификации.. 2

Связанные документы.. 2

Исполнители.. 2

Политика. 3

Определения. 3

Условия запуска. 3

Шаги.. 3

 

Процедура приёма новых систем на поддержку

 

Код

 

 

Цель документа

 

Регламентировать порядок приёма новых систем и отдельных модулей на поддержку

 

Модификации

 

Название	Версия	Дата	Тип модификации	Основание

 

Связанные документы

 

Название	Код	Версия	Создан	Характер связи

 

Исполнители

 

Роль	Описание
Менеджер проекта
Сотрудник службы поддержки систем мониторинга
Руководитель службы поддержки систем мониторинга
Разработчик пробников

 

Политика

 

Политика состоит в том, чтобы организовать максимально эффективную работу службы поддержки систем мониторинга и ОАМ по технической поддержке и обеспечению работоспособности систем и отдельных модулей разработанных и интегрированных компанией Bell Integrator.

Описание процесса управления инцидентами

Описание

процесса управления инцидентами

1 марта 2006г.

Содержание

ОСНОВНЫЕ ПОЛОЖЕНИЯ.. 2

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ.. 5

ВВЕДЕНИЕ.. 7

НАЗНАЧЕНИЕ.. 8

ЦЕЛИ.. 9

ЗАДАЧИ.. 10

ДЕЯТЕЛЬНОСТЬ В РАМКАХ ПРОЦЕССА.. 11

ПРЕИМУЩЕСТВА.. 13

РЕЗУЛЬТАТЫ… 14

УЧАСТНИКИ ПРОЦЕССА И ВЗАИМОДЕЙСТВИЕ.. 15

ПОРЯДОК УПРАВЛЕНИЯ ИНЦИДЕНТАМИ.. 17

КОНТРОЛЬ И ПРОВЕРКИ.. 18

ОТВЕТСТВЕННОСТЬ.. 19

СОВЕРЩЕНСТВОВАНИЕ ПРОЦЕССА.. 20

ПОЛИТИ ПРОЦЕССА.. 21

ОПИСАНИЕ РЕГЛАМЕНТОВ ПРОЦЕССА.. 23

Функциональные компоненты процесса. 25

Инструменты.. 26

ПЕРЕЧЕНЬ РОЛЕЙ.. 27

Менеджер процесса. 27

Специалист 1 и 2 уровня поддержки (дежурный инженер службы поддержки систем мониторинга). 28

Специалист 3 уровня поддержки (эксперт). 28

Специалист 4 уровня поддержки (разработчик). 29

Инициатор. 29

ВХОДЫ (ИСТОЧНИКИ ИНФОРМАЦИИ ОБ ИНЦИДЕНТАХ). 30

ВЫХОДЫ (РЕЗУЛЬТАТЫ ЗАКРЫТИЯ ИНЦИДЕНТОВ). 31

ПОКАЗАТЕЛИ КАЧЕСТВА (МЕТРИКИ). 32

Контактная информация. 34

История Документа. 35

ОСНОВНЫЕ ПОЛОЖЕНИЯ

Настоящий документ представляет собой описание процесса Управления инцидентами.

Изложенный материал сформирован на основании решений, принятых совместно специалистами отдела автоматизации мониторинга и специалистами дирекции по разработке компании “Bell Integrator” в период с 1 марта по 02 июня 2006 года.

Рабочий язык документа – русский. Использование английских терминов и сокращений допускается по согласованию.

Обновление и дополнение документа контролируется:

l на стадиях проектирования и тестирования — руководством отдела автоматизации мониторинга и специалистами дирекции по разработке при участии менеджера процесса;

l на стадиях внедрения и эксплуатации — Менеджером процесса Управления инцидентами.

Внутренний ИТ процесс Управление Инцидентами является одним из основных процессов, из которых состоит деятельность ОАМ.

Управление Инцидентами входит в группу процессов, обеспечивающих поддержку

функционирования и требуемый уровень эксплуатационных характеристик ИТ услуг,

предоставляемых ОАМ, и является штатным эксплуатационным процессом.

Процесс управления инцидентами организуется в ОАМ в соответствии с рекомендациями

ITIL (Information Technology Infrastructure Library) таким образом, чтобы обеспечить

Вводный инструктаж Группы поддержки инфраструктуры для нового сотрудника

Вводный инструктаж Группы поддержки инфраструктуры

для нового сотрудника

 

Пожалуйста, внимательно ознакомьтесь с приведенными ниже сведениями. Чтобы убедиться в однозначном понимании Вами предложенной ниже информации, ответьте на вопросы в конце документа. Надеемся, что изложенные сведения облегчат Вам использование инфраструктуры компании и взаимодействие с группой поддержки пользователей.

□     Конфигурация рабочей станции.

• Для ознакомления с детальной информацией о конфигурации предоставленной Вам рабочей станции запустите Msinfo32.exe.
• Процедуры плановой и внеплановой модернизации рабочей станции описаны в Policy 6720 Hardware Upgrade

Положение о группе технической поддержки

	Система менеджмента качества
	Положение о группе технической поддержки   Положение о подразделении

 

 

 

Причина разработки документа
Назначение
Содержание
Аудитория
Ссылки на другие документы
Версии
Условные обозначения
Файл
Авторские права

Содержание

 

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

2. Руководство группой и структура. 4

3. Основные задачи. 4

4. Функции. 5

5. Взаимодействие группы технической поддержки с другими структурными подразделениями предприятия. 5

6. Права. 6

7. Ответственность. 6

 

 

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

1.1. Группа технической поддержки является самостоятельным структурным подразделением, обеспечивающим деятельность предприятия и реализацию его задач и функций.

1.2.  Группа технической поддержки создается и ликвидируется приказом генерального директора предприятия.

1.3.  Группа технической поддержки создана с целью поддержки пользователей и обеспечения работоспособности программных продуктов, разработанных компанией и эксплуатирующихся заказчиком, в течение всего срока использования.

Положение о группе поддержки пользователей. Положение о подразделении

Система менеджмента качества

Положение о группе поддержки пользователей

Положение о подразделении

 

 

Причина разработки документа
Назначение
Содержание
Аудитория
Ссылки на другие документы
Версии
Условные обозначения
Файл
Авторские права

Содержание

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

2. Руководство группой и структура. 4

3. Основные задачи. 4

4. Функции. 5

5. Взаимодействие группы поддержки пользователей с другими структурными подразделениями предприятия. 6

6. Права. 6

7. Ответственность. 7

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

1.1. Группа поддержки пользователей является самостоятельным структурным подразделением, обеспечивающим деятельность предприятия и реализацию его задач и функций.