Семь шагов для создания эффективного ИТ-подразделения - Сергей Гредников Страница 13
Семь шагов для создания эффективного ИТ-подразделения - Сергей Гредников читать онлайн бесплатно
Шаг шестой – принятие работ по Заявке Заказчиком.
После завершения работ Исполнителем по Заявке, Заказчик получает оповещение о смене статуса Заявки. При необходимости проверки качества выполнения, пользователь тестирует (проверяет) полученный результат. В регламенте взаимодействия должен быть жестко описан срок, за который Заказчик выполняет необходимые действия со своей стороны для принятия решения о закрытии Заявки. Если претензий к качеству и полноте реализации Заявки Заказчик не имеет, то он закрывает Заявку (программное обеспечение должно иметь функционал, позволяющий зафиксировать эту операцию). Ели у Заказчика возникают вопросы и /или не удовлетворенность результатом, то Исполнитель выполняет устранение замечаний в строго отведенный срок и наоборот, если в течении отведенного времени (согласно регламента взаимодействия, обычно не более трех рабочих дней) от пользователя нет обратной связи, то ИТ-подразделение оставляет за собой право закрытия работ по Заявке. И только после этого работы считаются завершенными в полном объеме.
Программное обеспечение HelpDesk, является стандартным программным обеспечением, устанавливаемым на все рабочие места пользователей без дополнительных согласований и разрешений.
Конечно, при этом не отменяются традиционные методы обращения в ИТ-службу, но приоритет выполнения Заявок обязательно должен быть закреплен внутренним регулирующим документом по предприятию, например, регламентируемыми методами создания Заявки пользователем ИТ-сервиса ИТ-подразделению (в порядке убывания приоритета исполнения последним) могут быть:
– Заявка в специализированное программное обеспечение – Система регистрации заявок HelpDesk;
– Письменное обращение по установленной форме;
– Электронное письмо;
– Телефонное обращение;
– Личное обращение к специалистам ИТ-подразделения.
Во всех иных случаях обращения Заказчика к Исполнителю не рассматриваются как Заявка, и ИТ-подразделение не несет ответственности за результат обращения пользователя. При этом любое обращение в ИТ-подразделение отличного от создания заявки в HelpDesk должно быть, в последствии, отражено в вышеуказанном программном обеспечении.
Так, как программное обеспечение HelpDesk играет ключевую роль при организации взаимодействия ИТ-подразделения и пользователей, то для удобства пользователей, должна быть разработана подробная инструкция по созданию, порядку обработки и выполнению заявки в Системе регистрации заявок HelpDesk, которая должна быть введена в действие по правилам внутренней нормативной документации.
Вышеописанный пример приведен для Заявок, не требующих никаких согласований и/ или приобретения ТМЦ, другими словами в регламенте взаимодействия должны быть описаны все возможные варианты видов взаимодействия ИТ-подразделения и пользователей, что будет способствовать пониманию установленной последовательности действий, при появлении соответствующих потребностей у Заказчика.
Например, виды взаимодействия между Заказчиком и ИТ-подразделением могут быть определены следующими схемами:
– Сопровождение информационных сервисов, не требующих дополнительного разрешения контролирующих служб;
– Сопровождение информационных сервисов, требующих участия контролирующих служб/лиц;
– Внесение изменений в функционирующее программное обеспечение предоставляемых ИТ-сервисов предприятия;
– Техническое обслуживание компьютерной техники и периферийного оборудования;
– Техническое обслуживание телефонной связи и/ или корпоративной телефонной связи;
– Консалтинговые услуги;
– Расширение действующего функционала обслуживаемых ИТ-сервисов;
– Создание нового ИТ-сервиса предприятия включая автоматизацию производственных процессов;
– Расширение/модернизация физической топологии ЛВС Заказчика и другие.
Бывают случаи, когда общих схем взаимодействия, закрепленных в регламенте недостаточно или необходима детализация для конкретных ИТ-сервисов. В таких ситуациях руководством предприятия издается приказ по введению детализации к схеме взаимодействия с определением порядка и ответственности сторон. Ярким примером может служить предоставление доступа к программному обеспечению, содержащего персональные данные работников (ФЗ-152).
Когда отсутствуют процессы, то заменой им может быть опыт.
Когда нет опыта, то его могут заменить правила.
Когда отсутствуют правила, то есть только ритуалы.
Ритуалы – это начало хаоса.
Лао Цзы. Вольный перевод фрагмента сочинения «Дао Дэ Цзин»
В предыдущем разделе достаточно подробно был рассмотрен один из основных внешних регулирующих документов ИТ-подразделения – регламент взаимодействия ИТ-подразделения и структурных подразделений предприятия. Для эффективного функционирования данного регламента, руководитель ИТ-подразделения должен разработать и утвердить Соглашение об уровне сервиса (Service Level Agreement – SLA), информация и данные из которого лежит в основе всех последующих внутренних документов по ИТ-подразделению.
Целью документа Соглашение об уровне сервиса является: определение используемых сервисов, установление уровня обслуживания обозначенных сервисов, а также определение зон и мер ответственности сторон Соглашения как для потребителя ИТ-услуг – Заказчика (пользователей ИТ-сервисов) в рамках выполнения работ по предоставлению ИТ-услуг, так и для Исполнителя работ.
Обращения в службу HelpDesk Исполнителя обрабатываются в порядке их поступления. Максимальный срок реакции на обращение определяется установленным уровнем поддержки (SLA) по информационному сервису.
Также Соглашение отражает все тонкости и нюансы обработки обращения с высоким уровнем критичности, требующие экстренного вмешательства или консультации специалистов технической поддержки. К таким обращениям, прежде всего, относятся вопросы восстановления работоспособности. При этом вопросы, которые не могут быть решены с использованием существующего функционала продукта и/или аппаратного комплекса, передаются для решения специалистам для анализа и последующей разработки/изменения, с последующим выпуском обновления программного продукта и/или изменения технических характеристик аппаратного комплекса. Сроки выпуска обновления/изменения определяются в процессе диагностики проблемы и в соответствии с общим планом разработки программного продукта и/или закупки (модернизации) парка компьютерной техники. Время решения обращения может зависеть от критичности обращения, сложности решаемой проблемы и необходимости доработки и/ или модернизации ИТ-сервиса.
Все обращения классифицируются на различные уровни обслуживания. Уровни обслуживания отличаются временем реакции на обращение (и другими параметрами) и зависят от категории проблемы. Все уровни обслуживания должны быть определены и зафиксированы в Соглашении.
Жалоба
Напишите нам, и мы в срочном порядке примем меры.
Comments