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