ITSM с нуля, или С чего начать?

Логотип компании
ITSM с нуля, или С чего начать?
Движение ITSM становится все популярней в России. Многие руководители ИТ-направления в компаниях начинают задумываться, — «может и нам попробовать работать по общепризнанному стандарту?»

Движение ITSM становится все популярней в России. Многие руководители ИТ-направления в компаниях начинают задумываться, — «может и нам попробовать работать по общепризнанному стандарту?» — но тут же появляется масса других вопросов:

1. Какую пользу это принесет мне, как руководителю ИТ-направления?

2. Как объяснить бизнесу, что это ему тоже необходимо?

3. С чего начинать изменение процессов?

4. Какой фундамент следует заложить в самом начале?

Все эти вопросы, как правило, начинают отгонять мысли об ITSM и решение задачи откладывается в дальний ящик — «ладно, вернемся к этому как-нибудь в другой раз, когда будет свободное время». И как обычно это бывает, свободного времени не находится. Всегда есть «самые важные» и «очень срочные» дела.

Если вы об этом уже задумывались и ситуация вам знакома, значит эта статья для вас.

Что же делать?

Мудрец стыдится своих недостатков,

но не стыдится исправлять их.

Конфуций

Для того чтобы разорвать этот порочный круг, необходимо ответить на первый вопрос: «Какую пользу это принесет мне, как руководителю ИТ-направления?». Ответ на него и является отправной точкой, которая позволит понять, есть ли смысл что-то менять.

Начнем с того, что сама постановка данного вопроса некорректна. Пытаясь на него ответить, вы уже ставите себя в тупиковую ситуацию, ведь задача сводится к тому, чтобы убедить самого себя в том ITSM — это полезно. Необходимо перефразировать вопрос следующим образом: «Что именно я хочу улучшить в ИТ-подразделении?». Отвечая, можно понять, что именно в текущий момент вас больше всего беспокоит, в чем состоят слабые места подразделения, над которыми необходимо работать в первую очередь.

Анализируя полученный список, нужно построить план действий, предусматривающий не «внедрение ITSM-процессов», а проработку конкретных сформулированных вами направлений, требующих улучшения.

Важно осознать, что все стандарты, описанные в рамках ITSM, являются не руководством к действию, а всего лишь шаблоном-подсказкой, позволяющей адаптировать стандарт под собственное окружение и доработать любой процесс, исходя из конкретных потребностей.

Зри в корень

Как правило, одна из корневых проблем — отсутствие систематизированной информации внутри подразделения. Если на секунду отвлечься и задуматься, в чем же заключается роль любого ИТ-сервиса? Ответ очень простой: у пользователя есть один набор информации и он с помощью ИТ-инструментов хочет преобразовать его в другой набор, который для него имеет некую ценность. То есть основная функция ИТ — систематизация, обработка и преобразование информации из одного вида в другой. Тем не менее зачастую мы, как ИТ-подразделение, становимся «сапожниками без сапог»: автоматизируем бизнес-процессы всех подразделений компании, а на себя времени не хватает. Если сравнить ИТ-направление с другими подразделениями, оно является одним из самых информационно насыщенных. Наверное, такой объем информации и вызывает отсутствие желания ее систематизировать, но ведь именно бессистемность в работе с информацией приводит к недостаточной прозрачности процессов и результатов работы всего подразделения, а это в свою очередь влечет проблемы с планированием текущей деятельности и развития.

Именно по этой причине хочется посмотреть, как данная проблема решается в мировой практике. Мы ведь далеко не первые, кто задумался об этом.

Закладываем фундамент

ITSM проповедует идеологию сервисной ориентации ИТ-подразделения внутри компании. Направление информационных технологий несет в себе функции внедрения, предоставления, поддержки и модернизации услуг, которые предназначены для обеспечения бизнес-процессов других подразделений. Таким образом, отправной точкой является перечень услуг, предоставляемых бизнесу. Другими словами, в терминах ITSM необходимо составить сервис-каталог, или каталог услуг.

Отличное описание процесса создания каталога услуг приведено в статье «ПрофесCIOналы нового формата» в майском спецвыпуске журнала «IT-Manager», написанной президентом клуба ИТ-директоров Санкт-Петербурга Максимом Белоусовым ровно год назад. Именно совместная работа на проектах с Максимом послужила толчком к написанию данной статьи.

Создание каталога услуг — важный творческий процесс, требующий детальной проработки. Здесь закладывается фундамент, на котором будет строиться ваша собственная ITSM-пирамида. Каталог услуг — это некая классификация всего, чем занимается ваше подразделение. Когда я первый раз составил каталог, то сделал для себя много открытий. Во-первых, оказалось, что предоставляемых услуг гораздо больше, чем я представлял. Во-вторых, обнаружились услуги, о которых знали один-два человека во всем ИТ-подразделении.

Не буду вдаваться в детали долгого пути, который меня привел к текущей структуре каталога, а расскажу об основных принципах, полностью укладывающихся в идеологию ITSM.

Классификация услуг

Когда составляешь перечень услуг, которые предоставляются в подразделении, невольно задумываешься, что логично их сгруппировать, но при этом необходимо правильно выбрать критерии группировки.

Внешние и внутренние услуги

Первое, что необходимо сделать, — разделить услуги на внешние по отношению к ИТ-подразделению (услуги, направленные на обеспечение бизнес-процессов других подразделений компании) и внутренние, которые потребляет внутри ИТ-подразделение для обеспечения внешних услуг.

Почему-то именно эта часть вызывает у многих большие затруднения. Давайте представим, что ИТ-подразделение — это отдельная компания, предоставляющая свои услуги по договорам подразделениям-заказчикам. В вашей компании есть активы в виде инфраструктуры, СКС, а может, даже собственного ЦОДа, есть внутренние бизнес-процессы, которые обеспечивают работоспособность вашего бизнеса и активов, есть контрагенты, предоставляющие различные услуги, например каналы передачи данных, возможно, есть подрядчики на аутсорсинге по обслуживанию оргтехники. С другой стороны, у вас есть клиенты в виде других подразделений, которые являются потребителями ваших услуг. Такая модель довольно легко позволяет отделить внутренние услуги от внешних.

Особенность заключается в том, что требования к внешним услугам определяет подразделение-заказчик, требования к внутренним услугам — само ИТ-подразделение, для обеспечения необходимого уровня сервиса по внешним услугам.

Группировка по направлениям обслуживания

Если перечень услуг получается внушительный, то не обойтись без дополнительной группировки по направлениям. Это позволит применять общие требования к уровню сервиса, также при создании каталога и его автоматизации будет проще находить нужную услугу.

Вы можете придумать любую удобную для себя классификацию. Вот пример одной из них:

· Бизнес-приложения

· Стандартно ПО

· Специализированное ПО

· Рабочее место пользователя

· Телекоммуникации

· Оргтехника

· Специализированное оборудование

· и т. п.

Если говорить о внутренних услугах, классификация может выглядеть следующим образом:

· ИТ-инфраструктура

· Обеспечивающие услуги

· Вспомогательные услуги

Базовые характеристики услуг

Каждая услуга имеет определенные свойства, услуги могут сильно различаться между собой: например, «Подключение стационарного телефона» и «Поддержка ERP-системы» мало сравнимы между собой, тем не менее они тоже имеют общие черты. Во многом характеристики услуг могут зависеть от специфики работы компании. Если, скажем, сравнить услугу «Предоставление печати», для одной компании это может быть очень редкая и абсолютно неважная функция, для другой — основной бизнес-процесс, особенно если речь идет о сети копировальных центров. Ниже представлен перечень базовых характеристик.

Описание услуги

Направление обслуживания: здесь может быть использована любая подходящая классификация. Важно, чтобы она однозначно разделяла внешние и внутренние услуги и была удобна для применения.

Название услуги: казалось бы, это самая простая и понятная вещь, тем не менее самая распространенная ошибка, когда название не отражает состава услуги. Название должно быть таким, чтобы было понятно, что предусматривает услуга. Так, нельзя назвать услугу просто «Рабочее место», поскольку это не отражает ее сути. Правильное название должно звучать так: «Предоставление рабочего места», «Обслуживание рабочего места», «Модернизация рабочего места» и т. п. Может, более правильно было бы эту характеристику назвать «Предназначение услуги».

Краткое описание услуги – должно быть кратким, но емким и содержать описание возможностей/опций. Для услуги «Предоставление рабочего места» это будет выглядеть следующим образом: «Предоставление и базовое конфигурирование персонального компьютера или ноутбука, инсталляция операционной системы и стандартного программного обеспечения, установка и настройка телефонного аппарата». Когда составляете описание, представьте, что вы нанимаете подрядчика — что вы хотели бы увидеть в описании услуги?

Обязательные условия для предоставления услуги — описание условий, на которых предоставляется данная услуга: «Услуга поставляется пользователю по заявке на Service Desk при условии успешной сдачи теста по курсу SAP ERP».

Порядок предоставления услуги — здесь перечисляется последовательность действий, которые необходимо выполнить пользователю для того, чтобы получить услугу или отказаться от нее: «Подается стандартный запрос на обслуживание в Service Desk, в котором указана следующая уточняющая информация: ФИО, должность. К запросу должна быть приложена копия обоснования с подписью непосредственного руководителя»

Пользователи услуги — это перечень пользователей, групп пользователей или подразделений, которым предоставляется услуга. Некоторые услуги могут предоставляться всем сотрудникам.

Ответственные лица

Заказчик услуги — у любой услуги должен быть заказчик. Заказчиком услуги является представитель бизнеса, который устанавливает требования. Например, генеральный директор или ИТ-директор, как представитель бизнеса. Оптимальный вариант — наличие единого контактного лица, заинтересованного в предоставлении данной услуги, имеющего обоснованные бизнес-требования к ней.

Ответственный за оказание услуги — это ключевая фигура, которая отвечает за предоставление и поддержку услуги. К примеру, это может быть начальник службы поддержки пользователей или его подчиненные. Важно, чтобы такой человек не только нес ответственность, а действительно мог принимать решения и осуществлять действия, позволяющие соблюдать требования по услуге.

Ответственный за изменение услуги — это тот человек, который может принимать решения по модернизации, изменению или замене услуги. В крупных компаниях это руководитель направления по внедрению новых услуг и их изменению или его подчиненные, которые могут принимать подобные решения. В небольших компаниях это может быть объеденная роль вместе с ответственным лицом за оказание услуг.

Поставщик услуги — необходимо зафиксировать, какие ИТ-подразделения и/или внешние компании, являющиеся поставщиками услуг. Для внешних компаний так же нужно указать все необходимые контакты.

Соглашение об уровне предоставляемого сервиса

Схема оказания услуги — это время, в течение которого услуга может быть предоставлена. Это время можно разделить на несколько категорий, которые будут зависеть от специфики вашего бизнеса:

· 24×7 — услуга предоставляется 365 дней в году, 24 часа в сутки

· 8×5 — классификация для компаний, работающих по стандартному графику. Например, 12×8 или указан конкретный период времени — с 9:00 до 18:00 в будние дни и т. п.

· 8×5 по местному времени — аналог предыдущего пункта, привязанный к временному поясу в случае наличия офисов в разных часовых поясах.

Доступность — указывается в процентах. У каждой услуги должен быть гарантированный уровень доступности. Для контроля, в течение определенного периода времени вычисляется фактическая доступность, затем сравнивается с гарантированным уровнем, чтобы определить отклонение. Как рассчитывается доступность? Это достаточно просто. Предположим, речь идет о доступе к электронной почте, которая должна работать 24×7. Вы допускаете одни сутки простоя этого сервиса (планово и внепланово) в течение месяца. Высчитываем процент доступности за один год:

. Это и есть ваша плановая доступность. В течение всего года мы фиксируем время, в которое сервис не был доступен как при плановых остановках, так и при авариях. Важно отметить, что доступность считается пропорционально количеству сотрудников, которым предоставляется данная услуга. То есть если у вас в компании 1000 сотрудников, которые пользуются корпоративной почтой, при этом сервис не был доступен для 10 пользователей в течение трех часов, то процент простоя от годового времени доступности будет рассчитываться так:

Время реакции — время, в течение которого должен быть обработан запрос от пользователя, произведена его категоризация, выставлен приоритет, назначен исполнитель.

Время сопровождения услуги — время, когда осуществляется техническая поддержка. Это время зависит от вашей специфики и его описание схоже со «Схемой оказания услуги».

Время восстановления услуги после сбоя — время, в течение которого восстанавливается предоставление услуги, после внепланового прекращения ее работы. А также время, за которое будут ликвидированы последствия произошедшего внепланового перерыва в предоставлении услуги. То есть это время разрешение проблем после сбоя.

Дополнительная информация

Необходимые услуги для предоставления — перечень других услуг, которые должны быть предоставлены пользователю для возможности доступа к описываемой услуге.

Документы, регламентирующие работу с услугой, — перечень документов, регламентирующих предоставление услуги и инструкции по пользованию услугой.

Начало положено

Каталог услуг позволит вам подготовиться к любым дальнейшим надстройкам ITSM-процессов. Важно на этапе формирования каталога не погружаться в чрезмерное детализирование, это может привести к затягиванию, потери актуальности информации, да и просто любой длительный процесс сильно утомляет и демотивирует. Лучше сделать «хороший» каталог, чем не доделать «отличный».

Формирование каталога — это всего лишь первый шаг к изменениям, но он самый важный, поскольку в процессе его формирования появляется целостное понимание общей картины. Конечно, еще предстоит много дел по разработке, регламентации и внедрению новых процессов, но чем лучше проработана база, тем проще будет делать дальнейшие шаги.

Не забывайте, что без изменений не возможен прогресс. Желаю успехов!

Опубликовано 03.06.2013