5.2. Внутренние и внешние регулирующие документы
5.2. Внутренние и внешние регулирующие документы
Когда отсутствуют процессы, то заменой им может быть опыт.
Когда нет опыта, то его могут заменить правила.
Когда отсутствуют правила, то есть только ритуалы.
Ритуалы – это начало хаоса.
Лао Цзы. Вольный перевод фрагмента сочинения «Дао Дэ Цзин»
В предыдущем разделе достаточно подробно был рассмотрен один из основных внешних регулирующих документов ИТ-подразделения – регламент взаимодействия ИТ-подразделения и структурных подразделений предприятия. Для эффективного функционирования данного регламента, руководитель ИТ-подразделения должен разработать и утвердить Соглашение об уровне сервиса (Service Level Agreement – SLA), информация и данные из которого лежит в основе всех последующих внутренних документов по ИТ-подразделению.
Целью документа Соглашение об уровне сервиса является: определение используемых сервисов, установление уровня обслуживания обозначенных сервисов, а также определение зон и мер ответственности сторон Соглашения как для потребителя ИТ-услуг – Заказчика (пользователей ИТ-сервисов) в рамках выполнения работ по предоставлению ИТ-услуг, так и для Исполнителя работ.
Обращения в службу HelpDesk Исполнителя обрабатываются в порядке их поступления. Максимальный срок реакции на обращение определяется установленным уровнем поддержки (SLA) по информационному сервису.
Также Соглашение отражает все тонкости и нюансы обработки обращения с высоким уровнем критичности, требующие экстренного вмешательства или консультации специалистов технической поддержки. К таким обращениям, прежде всего, относятся вопросы восстановления работоспособности. При этом вопросы, которые не могут быть решены с использованием существующего функционала продукта и/или аппаратного комплекса, передаются для решения специалистам для анализа и последующей разработки/изменения, с последующим выпуском обновления программного продукта и/или изменения технических характеристик аппаратного комплекса. Сроки выпуска обновления/изменения определяются в процессе диагностики проблемы и в соответствии с общим планом разработки программного продукта и/или закупки (модернизации) парка компьютерной техники. Время решения обращения может зависеть от критичности обращения, сложности решаемой проблемы и необходимости доработки и/ или модернизации ИТ-сервиса.
Все обращения классифицируются на различные уровни обслуживания. Уровни обслуживания отличаются временем реакции на обращение (и другими параметрами) и зависят от категории проблемы. Все уровни обслуживания должны быть определены и зафиксированы в Соглашении.
В документе должен быть отражен такой критерий как время реакции ИТ-подразделения на Заявку, который определяется общей загрузкой технической поддержки Исполнителя и может быть меньше заявленного в Соглашении об уровне обслуживания. В некоторых случаях решение вопросов может производиться практически сразу же (мгновенно) по получении вопросов или дополнительной информации от пользователей информационных сервисов (потребителей ИТ-услуг). Реакция сотрудников службы технической поддержки Исполнителя на поступление дополнительной информации может быть дольше, но не больше максимального времени реакции, определенного для данного уровня технической поддержки информационного сервиса.
Соглашение должно предусматривать предоставление Исполнителем услуг с уровнем качества, определяемым и контролируемым набором показателей качества.
Качество работы, а также мера выполнения взятых на себя обязательств Исполнителем, может быть измерено соответствующими методиками, закрепленными в Соглашении, на основании анализа опросов удовлетворенности пользователей Заказчика и/или основании статистических данных из HelpDesk Исполнителя. Должна быть определена периодичность опросов, но не реже одного раза в квартал.
В Интернете или печатной литературе можно отыскать множество примеров построения основной таблицы SLA – уровень обслуживания и доступность ИТ-сервисов. Одни варианты более сложные, другие менее. Предлагаю читателю рассмотреть собственный вариант построения представления данной таблицы, опробованный на крупных предприятиях химической промышленности РФ, в котором отражены:
– Номер ИТ-сервиса по порядку
– Наименование информационного сервиса
– Назначение сервиса
– Детализация сервиса
– Количество пользователей
– Критичность сервиса
– Скорость реакции на неисправность (неработоспособность)
– Время предоставления информационного сервиса
– Время предоставления поддержки информационного сервиса
– Максимальное время неработоспособности в месяц
Шаблон таблицы SLA «уровень обслуживания и доступность ИТ-сервисов» представлен в приложении 2.
Хочу отметить, что логичным дополнением к таблице «уровень обслуживания и доступность» станет формирование перечня «Список готового (приобретенного) программного обеспечения в рамках предоставления ИТ-сервисов предприятия» со следующей структурой:
– Номер по порядку
– Наименование программного обеспечения
– Версия программного обеспечения
– Назначение программного обеспечения
– Количество лицензий
Подведем промежуточный итог: ИТ-подразделением уже подготовлены и внедрены следующие внешние регулирующие документы:
– Положение по подразделению.
– Должностные инструкции на каждую должность ИТ-подразделения.
– Приказом по предприятию организован Комитет по ИТ и разработано положение о Комитете по информационным технологиям.
– Приказом генерального директора/ директора предприятия введен в действие «Регламент обращения Стратегических инициатив в области автоматизации».
– Разработан регламент взаимодействия ИТ-подразделения и структурных подразделений предприятия. Регламент введен в должность приказом по предприятию.
– Согласовано и утверждено «Соглашение об уровне сервиса (SLA)».
– Разработан и внедрен «Регламент проведения регламентных работ».
Теперь ИТ-руководитель может приступить к формированию пакета внутренних регулирующих документов по подразделению, таких как:
– Регламент оформления технической документации.
– Регламент управления изменениями.
– Регламент взаимодействия исполнителей по выполнению заявок пользователей в Системе регистрации Заявок HelpDesk.
– Регламент предоставления и изменения прав доступа к программным ИТ-сервисам.
– Регламент разработки документа «Техническое задание».
– Функциональная матрица ответственности по ИТ-сервисам.
– И другие внутренние документы, например: Управление конфигурациями, Управление релизами.
Рассмотрим кратко основные аспекты, которые отражены по внутренних регулирующих документах.
Регламент оформления технической документации – основная цель данного документа вытекает из его названия: внедрение шаблона оформления технической документации для всех видов документов ИТ-подразделения: техническое задание, аналитическая записка, инструкция пользователя, руководство и т. п. Данный шаблон определяет требования не только к эстетическому оформлению выходного документа, но и определяет основные разделы. Например, каждый документ должен содержать:
– Содержание
– Свойства документа – кто, с какой целью, по какому проекту разработал, согласовал или изменил документ
– Общие сведения
– Определения и сокращения
– Характеристика и область применения
– Основание для разработки
– Основной раздел документа
– Примечания
Выполнение данного регламента является обязательным для всех направлений деятельности ИТ-подразделения, за исключением случаев, где оформление документации необходимо выполнять по ГОСТ.
Регламент управления изменениями. В процессе жизненного цикла во все ИТ-сервисы вносятся изменения. Причинами таких изменений обычно бывают:
– Изменение бизнес процессов;
– Устранение найденных ошибок;
– Расширение функциональных возможностей ИТ-сервиса;
– Улучшение эргономических свойств;
– Другие причины улучшающие характеристики предоставляемых ИТ-сервисов.
При внесении изменений в ИТ-сервис, с которым работает большое число пользователей и разработчиков, очень важно соблюдать определенный порядок и дисциплину. Это позволяет качественно планировать ресурсы и работы по модификации существующих ИТ-сервисов, отслеживать историю изменений и обеспечивать взаимозаменяемость сотрудников, планомерно повышать качество предоставляемых ИТ-сервисов.
К изменениям ИТ-сервисов относятся:
– изменения исходного кода программного обеспечения функционирующих информационных систем и программного обеспечения;
– изменения в структуре метаданных, нормативно-справочной информации, изменения печатных форм, а также изменения внешних отчетов и обработок функционирующего программного обеспечения;
– изменение и/или модернизация структурированных кабельных систем (витая пара, ВОЛС и т. д.), если при проведении работ возникает необходимость в установке дополнительного активного сетевого оборудования и/или перемещении уже установленного.
– изменение и/или модернизация кабельных сетей телефонной связи, если при проведении работ возникает необходимость в прокладке телефонного кабеля емкостью более 5 пар, установке новых телефонных распределительных коробок (либо перемещение уже установленных), а также в случае установки телефонных муфт, боксов, кросс-панелей, телефонных шкафов и т. д.
– изменение и/или модернизация объектов АСУТП как уровня программного обеспечения персональных компьютеров, так и контроллеров.
Ответственный специалист Исполнителя после получения Заявки Заказчика, руководствуясь Критериями отнесения Заявки Заказчика к ИТ-сервисам по Запросу на изменение, представленных в данном документе, определяет тип Заявки.
Заявка Заказчика относится к Запросу на изменение ИТ-сервиса, если для ее выполнения необходимо внести Изменение (-ия) в функционирующий ИТ-сервис, при условии, что расчетная трудоемкость выполнения Заявки Исполнителем менее 40 чел./часов.
Заявка Заказчика с трудоемкостью более 40 чел./часов могут быть (по согласованию Сторон) отнесены к классу «Проект» с оформлением соответствующей документации согласно действующим правилам и нормативным требованиям Заказчика.
Регламент взаимодействия исполнителей по выполнению заявок пользователей в Системе регистрации Заявок HelpDesk – данный документ является логическим продолжением инструкции пользователя по работе с «Системой регистрации Заявок HelpDesk», и описывает методы и принципы взаимодействия между ИТ-сотрудниками при реализации Заявки пользователей или Запросов на изменение. Также документ содержит шаблоны еженедельной отчетности по выполненным работам подразделения.
Регламент предоставления и изменения прав доступа к программным ИТ-сервисам – документ определяет процедуру и последовательность действий ИТ-специалистов, а также задействованных в процессе специалистов других подразделений и ответственных лиц при предоставлении и / или расширении прав доступа к конкретным ИТ-сервисам. Документ утверждается приказом генерального директора/ директором предприятия.
Регламент разработки документа «Техническое задание» – документ устанавливает состав, содержание, правила оформления документа «Техническое задание» (далее по тексту – ТЗ), разрабатываемого на автоматизированные системы управления (далее по тексту – АСУ) всех видов и для всех уровней управления на стадии «Технорабочий проект». Документ ТЗ создается для задач реализовываемых любого программного обеспечения, разрабатываемого в ИТ-подразделении, в т. ч. для задач по автоматизации производственных и технологических процессов. Техническое задание готовится при создании, развитии или модернизации автоматизированной системы (далее по тексту – АС), комплекса задач, задачи, программы или программного продукта. ТЗ входит в состав технической документации на АСУ в соответствии с ГОСТ 24.207—80. Данный регламент должен быть разработан в соответствии с требованиями Государственных стандартов на автоматизированные системы:
– Техническое задание на создание автоматизированной системы (ГОСТ 34.602—89)
– Техническое задание. Требования к содержанию и оформлению (ГОСТ 19.201—78)
– Требования к содержанию документа «Описание постановки задачи» (ГОСТ 24.204—80)
– Требования к содержанию документа «Описание алгоритма» (ГОСТ 24.211—82)
– ТЗ на АС является основным документом, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие, и предназначен для описания характеристик АС, условий реализации, входной и выходной информации.
Итоговым штрихом, является Функциональная матрица ответственности по ИТ-сервисам. Это таблица, которая описывает распределение поддерживаемых ИТ-сервисов предприятия между ИТ-специалистами с указанием функционального направления каждого специалиста по критерию: разработка (Development) и сопровождение (Support). Структура матрицы может быть представлена в следующем виде:
– Номер по порядку
– ФИО ИТ-специалиста
– Наименование ИТ-сервиса
– Разработка
– Сопровождение
После заполнения данной структуры все ИТ-сервисы должны быть закреплены и распределены по ИТ-специалистам. По окончании заполнения матрицы ИТ-руководителю необходимо выполнить еще один шаг: разработать и утвердить на уровне руководителя предприятия документ – «Распределение обязанностей и функций ИТ-персонала в разрезе предоставляемых ИТ-сервисов».
Структура таблицы представлена ниже.
Все эти документы и правила описанные в них способствуют созданию эффективной методики взаимодействия ИТ-подразделения и структурных подразделений предприятия, а также четного определения внутренних процессов ИТ. Причем правила взаимодействия и описания процессов представлены на понятном для бизнеса языке и согласованы всеми участниками.
Данный текст является ознакомительным фрагментом.