В № 15/2007 мы писали об очень интересном событии — открытии школы «Путь CIO». Максимально интерактивный формат занятий в школе включает в себя мастер-класс, который ведет президент Санкт-Петербургского клуба ИТ-директоров Максим Белоусов, завершающийся свободной сессией вопросов и ответов. Мы побывали на одном из занятий школы: дискуссии там разгораются совсем не шуточные и очень интересные. Поэтому начиная с этого номера мы открываем новую рубрику — «Школьные диалоги», где будем публиковать некоторые наиболее интересные моменты этих дискуссий. К сожалению, это лишь бледная копия того, что на самом деле происходит в центре событий. Но тут уж мы ничего поделать не можем.

Ученик: А для чего нужно создавать каталог сервисов? Понятно, что это рекомендуется методологией ITSM, что это лучшая мировая практика. Но что он принесет лично мне как ИТ-директору? В чем поможет?

Учитель: Поможет в самом главном — в определении того, что входит в зону твоей ответственности, за что ты отвечаешь. Регламенты компании и даже положение об ИТ-отделе не имеют большого смысла, пока вы не составите элементарный перечень существующих и используемых в компании ИТ-сервисов. Для того чтобы успешно работать, нужно некое соглашение, связанное с этими сервисами. Оно может быть даже не подписано и не иметь показателей, но в нём должно чётко определяться, как бизнес и ИТ-служба соответственно используют и поддерживают применяемые в компании ИТ. И чем тщательнее вы сделаете данный документ, тем легче будет вам работать.

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

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

Ученик: А разве и так не понятно, за что мы отвечаем?

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

Ученик: А как определять параметры восстановления сервисов, которые надо прописать в каталоге?

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

Поэтому для того, чтобы определить исходные параметры сервисов в каталоге, я сделал расчет, за сколько времени сотрудники ИТ-службы успевают восстановить тот или иной сервис. Вплоть до того, что с секундомером засекал время, за которое инженер-техник, например, заменит картридж на принтере. При этом замеры делались для самого удаленного объекта; учитывалось, что получив обращение, сотрудник не сразу срывается и бежит, так как у него есть и другие задачи, что вообще он должен не бежать, а идти (иначе долго ли он сможет бегать?). Я даже учитывал неизбежные перекуры и т. д. В результате я выяснил, например, что на замену картриджа в принтере нам требуется максимум 14 минут. Хотя команда, которая работала до меня, считала, что на это нужно не меньше часа.

Ученик: А как быть с бизнес-приложениями? Ведь там не получится прямым измерением определить параметры восстановления сервиса…

Учитель: На сто процентов не получится, но составить более подробное описание услуги, где будут описаны все вероятные особенности сбоев и варианты времени восстановления, ничто не мешает. Всё зависит от того, насколько вы как ИТ-директор в этом заинтересованы или насколько этого требует бизнес. Здесь действительно есть много тонкостей. Например, днем у нас произошел сбой в базе данных. Мы восстановили её с ночного «бэкапа». Значит, данные за первые пол­дня потеряны. Приложение работает? Да. Доступ к нему предоставлен? Да. А бизнес может пользоваться этим сервисом? Нет! Почему? Потому, что согласно описанию в каталоге предназначение услуги «КИС» — предоставлять информацию для работы сотрудников компании. И пока я не верну всех данных, необходимых для полноценной работы бизнеса, считается, что я не восстановил услугу!

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

Ученик: А параметры, которые прописаны в каталоге сервисов, например уровни обслуживания, — это SLA?

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

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

Ученик: А правила распределения сервисов в каталоге каковы? Электронную почту, например, куда относить — в ИТ-инфраструктуру или в приложения? И как поступать с сервисами, от которых зависит уровень поддержки других ИТ-услуг?

Учитель: Насчет почты, на мой взгляд, можно и так и так. Мне кажется, это не принципиально, куда ее включить. В целом я бы не рекомендовал слишком сильно беспокоиться по поводу того, как будет отражена взаимосвязь сервисов. Дело в том, что единого стандарта, как это надо сделать, не существует. Разные специалисты разделяют сервисы совершенно по-разному. Нельзя показать идеальный вариант. Например, вопрос, выделять ли ЦОД в отдельный сервис или нет, зависит и от его реального значения, и от отношения к ИТ-инфраструктуре в компании.

В заключение я хочу привести фразу из книги «Путь торговли» Тадао Ямагучи: «Никогда не надо усложнять действительно простых вещей». Создание каталога услуг кажется сложным. Тут и вправду много неясных вопросов. Но вы начните — и поймете, что многие вещи просты и решаются на уровне здравого смысла.

Если вам понравилась данная рубрика или вы хотите задать учителю вопрос, то добро пожаловать на форум «Школьные диалоги» на нашем сайте, или пишите по адресу: zimin@iemag.ru.