Также Соглашение отражает все тонкости и нюансы обработки обращения с высоким уровнем критичности, требующие экстренного вмешательства или консультации специалистов технической поддержки. К таким обращениям, прежде всего, относятся вопросы восстановления работоспособности. При этом вопросы, которые не могут быть решены с использованием существующего функционала продукта и/или аппаратного комплекса, передаются для решения специалистам для анализа и последующей разработки/изменения, с последующим выпуском обновления программного продукта и/или изменения технических характеристик аппаратного комплекса. Сроки выпуска обновления/изменения определяются в процессе диагностики проблемы и в соответствии с общим планом разработки программного продукта и/или закупки (модернизации) парка компьютерной техники. Время решения обращения может зависеть от критичности обращения, сложности решаемой проблемы и необходимости доработки и/ или модернизации ИТ-сервиса.
Все обращения классифицируются на различные уровни обслуживания. Уровни обслуживания отличаются временем реакции на обращение (и другими параметрами) и зависят от категории проблемы. Все уровни обслуживания должны быть определены и зафиксированы в Соглашении.
В документе должен быть отражен такой критерий как время реакции ИТ-подразделения на Заявку, который определяется общей загрузкой технической поддержки Исполнителя и может быть меньше заявленного в Соглашении об уровне обслуживания. В некоторых случаях решение вопросов может производиться практически сразу же (мгновенно) по получении вопросов или дополнительной информации от пользователей информационных сервисов (потребителей ИТ-услуг). Реакция сотрудников службы технической поддержки Исполнителя на поступление дополнительной информации может быть дольше, но не больше максимального времени реакции, определенного для данного уровня технической поддержки информационного сервиса.
Соглашение должно предусматривать предоставление Исполнителем услуг с уровнем качества, определяемым и контролируемым набором показателей качества.
Качество работы, а также мера выполнения взятых на себя обязательств Исполнителем, может быть измерено соответствующими методиками, закрепленными в Соглашении, на основании анализа опросов удовлетворенности пользователей Заказчика и/или основании статистических данных из 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). Структура матрицы может быть представлена в следующем виде:
– Номер по порядку
– ФИО ИТ-специалиста
– Наименование ИТ-сервиса
– Разработка
– Сопровождение
После заполнения данной структуры все ИТ-сервисы должны быть закреплены и распределены по ИТ-специалистам. По окончании заполнения матрицы ИТ-руководителю необходимо выполнить еще один шаг: разработать и утвердить на уровне руководителя предприятия документ – "Распределение обязанностей и функций ИТ-персонала в разрезе предоставляемых ИТ-сервисов".
Структура таблицы представлена ниже.
Все эти документы и правила описанные в них способствуют созданию эффективной методики взаимодействия ИТ-подразделения и структурных подразделений предприятия, а также четного определения внутренних процессов ИТ. Причем правила взаимодействия и описания процессов представлены на понятном для бизнеса языке и согласованы всеми участниками.
6. Применение средств автоматизации в ИТ подразделении
В рамках оптимизации ручного труда при заполнении отчетности, требуемой для оценки эффективности деятельности ИТ-подразделения в целом и каждого отдельно взятого ИТ-специалиста и повседневной деятельности возможно применение программного обеспечения. Так, например, программное обеспечение HelpDesk не только выполняет функции сбора поступивших Заявок от пользователей ИТ-сервисов и их обработки, но и в своем функционале должно содержать модули бизнес-анализа (BI – Business Inteligence). Данные модули должны позволять выполнять анализ в различных разрезах, с целью формирования отчетности по всем направлениям деятельности подразделения и контроля ключевых показателей эффективности. Примером отчетности могут служить следующие:
– Диаграмма количество открытых Заявок пользователей по подразделениям;
– Диаграмма количество открытых Заявок пользователей по сервисам;
– Динамика количества закрытых заявок в разрезе ИТ-сервисов по отношению к поступившим за период;
– Количество открытых/закрытых изменений в разрезе ИТ-сервисов;
– Количество выполненных заявок пользователей в разрезе ИТ-специалистов и ИТ-сервисов за период;
– Количество просроченных заявок в различных аналитических разрезах
– Количество заявок с перенесенными сроками выполнения в разрезе ИТ-сервисов и группировкой по причинам переноса и т. п.
Отдельным направлением автоматизации внутренних бизнес процессов ИТ-подразделения, с целью контроля расхода ресурсов, является учет рабочего времени ИТ-персонала. В основе алгоритмов программного обеспечения лежат методы хронометража рабочего времени. Давайте рассмотрим основной принцип работы такого программного обеспечения, т. к. детальное описание данного решение занимает не один десяток страниц и может являться материалом для уже другой книги.
Итак, в первую очередь, необходимо отметить, что "Учет рабочего времени" может являться как функциональным блоком программного обеспечения HelpDesk, так и быть независимой реализацией, но тогда, должны существовать интеграционные механизмы с системой сбора и обработки заявок.
Любой ИТ-специалист, получая Заявку от пользователей выполняет определенный комплекс работ с ней, например: анализ, формирование и согласование технических требований реализации, собственно реализация задачи, тестирование результата, написание технической документации и, как итог, сдача работы Заказчику. И конечно же, временные затраты на каждом этапе выполнения работ не одинаковы. А теперь умножим временные затраты по каждой задаче в разрезе выполняемых работ. На выходе трудоемкость всего ИТ-подразделения, необходимая для анализа эффективности как отдельного направления деятельности или ИТ-сотрудника, так и подразделения в целом.
При этом, для полноценной фиксации затраченных ресурсов ИТ-специалистов необходима классификация работ по бизнес-процессам, а это не что иное как каталог ИТ-услуг для конечного потребителя (Заказчика), который является неотъемлемой частью SLA. Зная затраты по фонду оплаты труда ИТ-специалистов, стоимости аренды помещений, занимаемых ИТ-службой, налогам, затратам, связанных с поддержанием внутренних бизнес-процессов ИТ-подразделения, затраты на обучение и другие, возможно подсчитать стоимость каждого бизнес-процесса. Примером структуры Каталога ИТ-услуг может быть:
– Обслуживание оргтехники
– Услуги администрирования
– Услуги связи
– Поддержка и сопровождение бизнес-приложений
– Разработка и внедрение бизнес-приложений
– Общие информационно-консалтинговые услуги
– Поддержка и сопровождение средств АСУТП
– Разработка и внедрение средств АСУТП
Причем в Каталоге ИТ-услуг однозначно определены виды работ по каждой из ИТ-услуг и дана полная расшифровка выполняемых работ по ним. Пример построения каталога ИТ-услуг приведен в
Применение Каталога ИТ-услуг дает эффект и в получении дополнительной бизнес-аналитики: в стоимостном выражении по потребителям ИТ-услуг (очень полезный инструмент при расчете фактической себестоимости готовой продукции по предприятию), а также дает понимание структуры потребления ИТ-услуг по предприятию в целом.
Конечно же, решение о применении тех или иных средств автоматизации – это решение руководства предприятия. Но все эти решения должны способствовать повышению эффективности ИТ-подразделения и его уровня зрелости бизнес-процессов.
7. Инструменты контроля эффективности ИТ-подразделения
Одним из самых сложных вопросов при работе с ИТ-подразделением является оценка его эффективности. Количество персональных компьютеров, количество ИТ-сервисов, предоставляемых пользователям, количество часов, потраченных на поддержку пользователей, общее количество абонентов внутренней телефонной станции не помогут в оценке. Если предприятие хорошо управляется, значит, что управление организовано так, что руководители заинтересованы в том, чтобы предприятие работало на пределе эффективности. Предел эффективности может быть определен эмпирически и достигнут только тогда, когда менеджеры первого звена хорошо понимают каким образом разные структурные подразделения предприятия, в том числе и ИТ, должны быть эффективно использованы. При этом, чтобы эффективно управлять, необходимо измерять текущее положение, цели и достигнутые результаты. Необходимо оценивать и сравнивать различные направления и способы инвестирования в ИТ, определять наиболее рациональные, в том числе, с учетом дефицита ресурсов.
Базовое решение – применение системы сбалансированных показателей – оценивая ключевые показатели ИТ, привязанные к бизнес-стратегии и ключевым бизнес-процессам предприятия, можно сделать вывод об эффективности ИТ-подразделения. Конечно, вопрос внедрения системы управления по целям – это сложный и трудоемкий процесс, решается в масштабах всего предприятия и ее (система KPI – Key Perfomance Indikator, Ключевые показатели эффективности) внедрение нецелесообразно делать только применительно к ИТ-подразделению.