Для выполнения вышеуказанных работ может потребоваться доступ в монопольном режиме к ИТ-сервисам, т. е. когда доступ к базам данных или программному обеспечению разрешен только одному пользователю – администратору. Такой период времени называется "Регламентный перерыв" и в это время, определенное регламентом, в течение которого информационные системы или другие ИТ-сервисы недоступны для работы пользователям.
Запланированные регламентные перерывы целесообразно проводить в течение рабочего дня в строго отведенное для этих работ время, что позволит обеспечить требуемое качество предоставляемых ИТ-сервисов.
Периодичность и время проведения плановых регламентных перерывов по всем информационным сервисам устанавливается регламентом проведения регламентных работ.
Раздел плана "Прочее", может содержать следующие работы:
– Совещания внешние
– Совещания внутренние
– Работа с организационно-распорядительной документацией
– Переписка с партнерскими организациями
– Подготовка финансовых документов
– Договорная деятельность
– Сканирование, печать документов
– Подготовка отчетов
– Обучение, повышение квалификации
– Прочие работы, сложно учитываемые по времени – работы не вошедшие не в один раздел
– Отсутствие специалистов (простои, отпуска, отгулы, административные, больничные)
После того, как все поступившие Заявки пользователей распределены по разделам и определено плановое время по разделам "регламентные работы" и "прочее", ИТ-руководителю становятся доступны "свободные" часы по направлениям деятельности (функциям ИТ-подразделения) – время, которое может быть израсходовано на выполнение поступающих Заявок пользователей в планируемом периоде. В случае, если планирование трудоемкости выполнения уже поступивших задач в ИТ-подразделение выполняется по каждому сотруднику, то руководитель ИТ-подразделения видит "свободные" часы по каждому сотруднику, что в свою очередь позволяет более точно оценить возможности ИТ-подразделения для выполнения сверхплановых задач.
Подготавливать текущий план слишком заранее не следует, т. к. он не будет содержать актуальную картину по планируемой трудоемкости, т. к. заявки от пользователей могут поступать в независимости от времени года. Целесообразнее всего подготовить документ за 7-10 рабочих дней до начала планируемого периода.
В любом случае, при формировании текущего плана работ по ИТ-подразделению не стоит забывать, что все задачи включенные в план должны соответствовать принципу SMART:
– Конкретность (S),
– Измеримость (M),
– Достижимость (A),
– Значимость (R),
– Соотношение с конкретным сроком (T)
Если же у ИТ-руководителя есть автоматизированный инструмент планирования работ и фиксации факта по выполненным работам с возможностями формирования отчетов в различных разрезах, то это замечательно, т. к. если в штате более 100 человек, то обработать такие объемы информации в ручную – непростая задача.
5. Взаимодействие с Заказчиком
Ранее рассматривался вопрос формирования плана по ИТ-подразделению на основе поступивших Заявок от пользователей ИТ-сервисов. Возникает вопрос: как сделать процесс сбора Заявок эффективным? Это один из вопросов, который необходимо решить руководителю ИТ-подразделения в целях оптимизации времени на реагирование ИТ-подразделения на текущую потребность пользователя. Другими словами, завтра "раки по пять рублей" уже не нужны – они нужны сегодня и по "три рубля", а может и наоборот: завтра "раки даже по три рубля" не нужны, они нужны сегодня пусть и по пять.
Наиболее подходящее решение – это применение аппаратно программного комплекса (далее по тексту – АПК), позволяющего обрабатывать Заявки пользователей и накапливать статистику по выполненным Заявкам в различных разрезах. Применение АПК существенно сокращает время прохождения запроса от момента его инициации до принятия в работу конкретным ИТ-специалистом. Также при применении АПК наблюдается экономия расходных материалов таких как: офисная бумага, картриджи и/ или тонер, при условии заправки картриджей силами ИТ-подразделения. При появлении истории обработки (выполнения) Заявок, появляются возможности проведения аналитических исследований и формирования базы знаний предприятия. Отдельным плюсом необходимо отметить перераспределение нагрузки на ИТ-персонал, например: программист должен программировать, а не "срочно" отвечать на вопрос пользователя, который пришел к нему и ждет очереди (из других таких же пользователей), когда тот освободится! Для подобных вопросов организована первая линия поддержки и, в случае, если оператор HelpDesk или группа внедрения и сопровождения не смогла предоставить ответ пользователю, вот тогда идет обращение на второй и третий уровни поддержки (согласно принципов методологии ITIL (IT Infrastructure Library, библиотека инфраструктуры информационных технологий)). Стоит отметить, что и пользователь не тратит свое время в пустую, зная, что на его запрос поступит ответ в заранее обговоренное и согласованное время.
Таким образом применение АПК позволит не только построить эффективное взаимодействие с Заказчиком – конечным потребителей ИТ-услуг, но и будет способствовать повышению качества предоставляемых ИТ-сервисов пользователям. В общем случае, схема взаимодействия потребителей ИТ-услуг (пользователей ИТ-сервисов) и ИТ-подразделения представлена на. Стоит отметить, что внедрение АПК, на уровне зрелости ИТ-подразделения от нулевого до второго (согласно методики оценки уровня зрелости ИТ по CobiT), является Стратегической целью развития ИТ на предприятии.
Вариантов программного обеспечения на рынке достаточно и каждое предприятие может выбрать решение, которое удовлетворяет всем его запросам и потребностям. Также никто не запрещает разработать и внедрить собственное решение, но всегда нужно помнить об эффективности и трезво оценивать окупаемость инвестиций.
На представленной ниже схеме взаимодействия, приведено логическое разделение на первую, вторую и третью линии поддержки пользователей; организационно каждое направление (функция ИТ) может быть выделено в самостоятельную группу, так например: в рассмотренном примере ранее служба технической поддержки или техподдержка (Technical support, Helpdesk, Service desk) – сервисная структура отдела поддержки пользователей, разрешающая проблемы пользователей с компьютерами (как аппаратным, так и программным обеспечением) и периферийным оборудованием. Данная служба является единым центром приема Заявок пользователей и их дальнейшей обработки (назначение ответственных, сроков выполнения и т. п.).
Рисунок 4. Схема взаимодействия структурных подразделений предприятия и ИТ-подразделения
В последующем разделе рассмотрим общую схему взаимодействия более подробно.
5.1. Организация взаимодействия
Для удобства дальнейшего изложения материала, аппаратно-программный комплекс, используемый для приема, регистрации заявок, контроля за выполнением работ, а также для получения статистики по Заявкам будем называть – HelpDesk, а специалистов, отвечающих за прием и распределение Заявок – менеджерами HelpDesk.
Согласно приведенной схеме на., основанием для выполнения работ сотрудниками ИТ-подразделения является Заявка Заказчика в специализированное программное обеспечение – Система регистрации заявок HelpDesk. Данное программное обеспечение становится единой точкой входа/выхода информации для ИТ-подразделения, следовательно исключительную важность в организации взаимодействия играет бизнес-процесс обработки Заявок пользователей.
Далее кратко рассмотрим бизнес-процесс работы с Заявками с применением программного обеспечения HelpDesk, состоящий из нескольких основных шагов.
Шаг первый – прием Заявки пользователя.
При поступлении новой заявки менеджеру HelpDesk приходит оповещение на электронную почту. Менеджер HelpDesk проводит первоначальный анализ заявки. В следующих случаях, когда нет возможности выполнить заявку по одной из следующих причин:
– Дублирующая заявка
– Не входит в компетенцию ИТ-подразделения
– Заявка снята Заказчиком
– Не согласовано с СБ и/или Руководителем по направлению
– Ошибка/неисправность не обнаружена
– Отсутствует техническая возможность
– Не запланирован бюджет
– Нет ТМЦ в наличии (по возможности не рекомендуется применять, а использовать механизм перенесения сроков, по договоренности с Заказчиком на более поздний период)
– Не поддерживаемый ИТ-сервис (отсутствует в списке SLA)
– Недостаточно информации для выполнения Задачи
– Незаинтересованность пользователя
– Другое (необходима расшифровка)
применяется инструмент "Мотивированный отказ".
Шаг второй – назначение Исполнителя работ по Заявке.
Если заявка принята в работу, возможны следующие варианты назначения Исполнителя:
Менеджер HelpDesk назначает исполнителем по заявке себя в случаях, если работы будут выполнены менеджером HelpDesk, если в заявке недостаточно исходных данных. Менеджер HelpDesk добавляет комментарий в заявку о необходимости предоставить дополнительную информацию. Если запрашиваемые данные по истечении трех дней не предоставлены, делает мотивированный отказ с указанием его обоснования.
При поступлении новой заявки по программному ИТ-сервису, требующей изменения программного обеспечения, Исполнителем назначается руководитель отдела разработки и внедрения информационных систем или руководитель подразделения АСУТП, который затем назначает Исполнителя из сотрудников своего отдела или передает заявку в работу сторонним организациям, осуществляющим третью линию поддержки по данному ИТ-сервису.
В прочих случаях Исполнитель по заявке назначается в соответствии с ИТ-сервисом.
Для обеспечения выполнения выше представленной схемы менеджер HelpDesk должен владеть следующей информацией:
Действующий каталог ИТ-сервисов предприятия – обычно перечень ИТ-сервисов закрепляется SLA;
Матрицей распределения ИТ-сервисов за ИТ-сотрудниками с указанием исполняемых функций по ИТ-сервису.
Утвержденный каталог выполняемых работ специалистами ИТ-подразделения.
Действующий регламент управления изменениями на предприятии, отражающий последовательность действий, в случаях внесения изменений в программное обеспечение, инфраструктуру, связь, АСУТП и т. п.
Шаг третий – установка плановых сроков выполнения работ Исполнителем работ по Заявке.
Минимальный срок выполнения работ по Заявке устанавливается три дня.
В случае если менеджер HelpDesk не может самостоятельно определить срок выполнения работ по заявке, он согласовывает сроки с конечным исполнителем по Заявке.
Шаг четвертый – выполнение работ Исполнителем работ по Заявке.
Далее, Исполнитель проводит окончательный анализ поступившей заявки. Руководствуясь регламентирующими документами по ИТ-сервису, наличием или отсутствием технической возможности реализации заявки, Исполнитель принимает заявку в работу или делает "Мотивированный отказ" с указанием его обоснования.
При приеме заявки в работу Исполнитель оценивает плановую трудоемкость работ, текущую загруженность по ранее поступившим заявкам и, при необходимости, изменяет сроки работ с помощью инструмента "Изменить сроки" с обязательным указанием обоснования. Этим инструментом также можно воспользоваться в ходе выполнения работ по заявке. Но, всегда при перенесении сроков выполнения работ по Заявке, Исполнитель должен согласовывать этот перенос с Заказчиком.
При необходимости привлечения других Исполнителей к выполнению работ по Заявке, или в случае выполнения работ по разным позициям каталога работ ИТ-подразделения, создается связанная заявка от имени автора (Заказчика) основной заявки. Причем, о всех происходящих действиях по Заявке, Заказчик уведомляется посредством электронной почты.
В случае, если работы по заявке будут выполнены позднее по объективным причинам, такие как отсутствие технической возможности до конкретного срока, задержка финансирования, приостановка проекта и т. п., Исполнитель может использовать инструмент "Отложить заявку" с обязательным указанием обоснования.
В ходе выполнения работ по заявке для уточнения возникающих вопросов, в программном обеспечении должен быть предусмотрен механизм коммуникации Исполнителя и Заказчика, который используется для фиксации переписки по Заявке, а также предоставляет возможность прикладывать к Заявке дополнительные файлы.
В случае необходимости, заявка может быть переведена в состояние "Изменение" в соответствии с действующим регламентом управления изменениями на предприятии. Ответственность за выполнение работ по изменениям возлагается на руководителя подразделения, в чью функциональную обязанность входит предоставление того или иного информационного сервиса.
Шаг пятый – завершение выполнения работ Исполнителем работ по Заявке.
После выполнения всех работ по заявке, Исполнитель оценивает фактическое время, затраченное на выполнение работ по заявке, фиксирует его и завершает работы с предоставление краткого отчета о выполненных работах.
Шаг шестой – принятие работ по Заявке Заказчиком.
После завершения работ Исполнителем по Заявке, Заказчик получает оповещение о смене статуса Заявки. При необходимости проверки качества выполнения, пользователь тестирует (проверяет) полученный результат. В регламенте взаимодействия должен быть жестко описан срок, за который Заказчик выполняет необходимые действия со своей стороны для принятия решения о закрытии Заявки. Если претензий к качеству и полноте реализации Заявки Заказчик не имеет, то он закрывает Заявку (программное обеспечение должно иметь функционал, позволяющий зафиксировать эту операцию). Ели у Заказчика возникают вопросы и /или не удовлетворенность результатом, то Исполнитель выполняет устранение замечаний в строго отведенный срок и наоборот, если в течении отведенного времени (согласно регламента взаимодействия, обычно не более трех рабочих дней) от пользователя нет обратной связи, то ИТ-подразделение оставляет за собой право закрытия работ по Заявке. И только после этого работы считаются завершенными в полном объеме.
Программное обеспечение HelpDesk, является стандартным программным обеспечением, устанавливаемым на все рабочие места пользователей без дополнительных согласований и разрешений.
Конечно, при этом не отменяются традиционные методы обращения в ИТ-службу, но приоритет выполнения Заявок обязательно должен быть закреплен внутренним регулирующим документом по предприятию, например, регламентируемыми методами создания Заявки пользователем ИТ-сервиса ИТ-подразделению (в порядке убывания приоритета исполнения последним) могут быть:
– Заявка в специализированное программное обеспечение – Система регистрации заявок HelpDesk;
– Письменное обращение по установленной форме;
– Электронное письмо;
– Телефонное обращение;
– Личное обращение к специалистам ИТ-подразделения.
Во всех иных случаях обращения Заказчика к Исполнителю не рассматриваются как Заявка, и ИТ-подразделение не несет ответственности за результат обращения пользователя. При этом любое обращение в ИТ-подразделение отличного от создания заявки в HelpDesk должно быть, в последствии, отражено в вышеуказанном программном обеспечении.
Так, как программное обеспечение HelpDesk играет ключевую роль при организации взаимодействия ИТ-подразделения и пользователей, то для удобства пользователей, должна быть разработана подробная инструкция по созданию, порядку обработки и выполнению заявки в Системе регистрации заявок HelpDesk, которая должна быть введена в действие по правилам внутренней нормативной документации.
Вышеописанный пример приведен для Заявок, не требующих никаких согласований и/ или приобретения ТМЦ, другими словами в регламенте взаимодействия должны быть описаны все возможные варианты видов взаимодействия ИТ-подразделения и пользователей, что будет способствовать пониманию установленной последовательности действий, при появлении соответствующих потребностей у Заказчика.
Например, виды взаимодействия между Заказчиком и ИТ-подразделением могут быть определены следующими схемами:
– Сопровождение информационных сервисов, не требующих дополнительного разрешения контролирующих служб;
– Сопровождение информационных сервисов, требующих участия контролирующих служб/лиц;
– Внесение изменений в функционирующее программное обеспечение предоставляемых ИТ-сервисов предприятия;
– Техническое обслуживание компьютерной техники и периферийного оборудования;
– Техническое обслуживание телефонной связи и/ или корпоративной телефонной связи;
– Консалтинговые услуги;
– Расширение действующего функционала обслуживаемых ИТ-сервисов;
– Создание нового ИТ-сервиса предприятия включая автоматизацию производственных процессов;
– Расширение/модернизация физической топологии ЛВС Заказчика и другие.
Бывают случаи, когда общих схем взаимодействия, закрепленных в регламенте недостаточно или необходима детализация для конкретных ИТ-сервисов. В таких ситуациях руководством предприятия издается приказ по введению детализации к схеме взаимодействия с определением порядка и ответственности сторон. Ярким примером может служить предоставление доступа к программному обеспечению, содержащего персональные данные работников (ФЗ-152).
5.2. Внутренние и внешние регулирующие документы
Когда отсутствуют процессы, то заменой им может быть опыт.
Когда нет опыта, то его могут заменить правила.
Когда отсутствуют правила, то есть только ритуалы.
Ритуалы – это начало хаоса.
Лао Цзы. Вольный перевод фрагмента сочинения "Дао Дэ Цзин"
В предыдущем разделе достаточно подробно был рассмотрен один из основных внешних регулирующих документов ИТ-подразделения – регламент взаимодействия ИТ-подразделения и структурных подразделений предприятия. Для эффективного функционирования данного регламента, руководитель ИТ-подразделения должен разработать и утвердить Соглашение об уровне сервиса (Service Level Agreement – SLA), информация и данные из которого лежит в основе всех последующих внутренних документов по ИТ-подразделению.
Целью документа Соглашение об уровне сервиса является: определение используемых сервисов, установление уровня обслуживания обозначенных сервисов, а также определение зон и мер ответственности сторон Соглашения как для потребителя ИТ-услуг – Заказчика (пользователей ИТ-сервисов) в рамках выполнения работ по предоставлению ИТ-услуг, так и для Исполнителя работ.
Обращения в службу HelpDesk Исполнителя обрабатываются в порядке их поступления. Максимальный срок реакции на обращение определяется установленным уровнем поддержки (SLA) по информационному сервису.