О создании каталога услуг (КУ) уже написаны целые книги, но, как правило, их авторами являются западные эксперты. Пока ещё мало практики создания каталога услуг, при реализации подобных проектов CIO сталкиваются со множеством подводных камней. Максим Белоусов, директор по ИТ холдинга «Аконит» и президент «SPb CIO Club», на основе собственного богатого опыта выделил наиболее важные моменты, с которыми он сталкивался при создании каталога ИТ-услуг в своей компании.

Intelligent Enterprise: Каковы предпосылки к созданию каталога ИТ-услуг?

Максим Белоусов: Руководители по ИТ нередко получают от бизнеса задачу: «Чтобы все работало». Для нас — CIO — слово «всё» понятие очень сложное. Нам нужно разобраться, что оно в себя включает, т. е. понять, к каким объектам ИС следует прилагать усилия, какие ИТ нужны бизнесу и что он хочет получить от их использования. Став главой клуба ИТ-директоров и поддерживая политику сервисно-ориентированного подхода к работе ИТ-службы, я по­знакомился с массой примеров того, какие именно причины побуждали бизнес задумываться о КУ.

Наиболее классические западные представления по данному вопросу заключаются в том, что существуют предпосылки, связанные с необходимостью оценки обслуживания ИТ с точки зрения их ресурсоемкости и стоимости. Я это называю внешними потребностями. К ним же можно отнести неудовлетворенность бизнеса качеством обслуживания ИТ-сервисов. Но мне чаще всего приходилось сталкиваться с так называемыми внутренними потребностями CIO, которые связаны с определением объектов обслуживания. Многим руководителям для построения эффективной поддержки ИТ-инфраструктуры жизненно необходимо иметь перечень ИТ-сервисов.

Каковы цели создания каталога ИТ-услуг?

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

Следующая цель — прозрачность предоставления ИТ-услуг. Это амбициозная задача любого ИТ-директора: показать, что мы работаем и отрабатываем деньги. Иными словами, нужна PR-поддержка предоставления ИТ-услуг. И первое, что для этого надо сделать, — создать каталог сервисов. К сожалению, по отношению к ИТ-службе у руководителей бытует такое мнение: «Зачем им нужны деньги? Я их не дам, поскольку и без того на ИТ много трачу!». Одному из своих коллег я задал вопрос, какова для него цель создания каталога услуг. И он ответил: «Чтобы объяснить бизнесу, что деньги, выделяемые на ИТ, тратятся не на меня лично и даже не на ИТ-службу, а на поддерж­ание бизнеса».

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

А если он это знает, то взаимодействие с ним будет простым и бесконфликтным. Поэтому одной из важнейших целей создания каталога является построение долгосрочных отношений между ИТ-службой и бизнесом. Один известный специалист в области сервис-менеджмента Майкл Мак-Гоги писал, что цель создания каталога сервисов — это управление ожиданиями пользователей в отношении ИТ. Пока пользователи не знают, что услуга «КИС» поддерживается с 8.00 до 22.00, они думают, что сотрудники ИТ-службы сидят на работе всю ночь. Четкое описание формирует их ожидания. Еще одна цель — подготовка требований к аутсорсинговым услугам. Несомненно, нужно понимать, какие требования должны быть выставлены, скажем, к поставщикам телекоммуникационных услуг.

Западные специалисты в качест­ве цели называют также управление издержками на обслуживание. Цель несомненно важная, но с одной поправкой: управление издержками на обслуживание прежде всего нужно бизнесу. Сколько платить и как управлять стоимостью — об этом думает финансовый директор вместе с собственником компании. Если они считают, что нужно сокращать издержки, то мой ответ им простой: «Сокращайте, но сначала посмотрите, к каким сервисам привязаны сокращаемые вами ресурсы». Ведь может получиться так, что без достаточного финансирования часть серверов перестанет функционировать.

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

Для меня основной целью является «совершенствование работы ИТ-службы путем конкретизации процессов сопровождения и объектов / сервисов ИТ-инфраструктуры». Это значит: цель CIO — понять, за что ИТ-служба получает деньги, и объяснить бизнесу, что деньги, выделяемые на ИТ, тратятся не на ИТ-службу, а на поддержание бизнеса. А цель руковод­ства — разобраться, какие ИТ необходимы бизнесу, какова ИТ-составляющая бизнес-процессов компании и ее стоимость.

Расскажите о процессе создания каталога. На какие этапы делится этот проект?

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

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

Наконец, третий этап — каталог «для пользователей». Кроме короткого описания сервиса и его характеристик в КУ для пользователей необходимо создать регламенты с описанием правил использования сервисов. Почему нужно обращать внимание на регламенты? Потому что я не могу в каталоге услуг подробно объяснять, как предоставляется и сопровождается каждый сервис, — тогда получился бы очень объемный документ. Поэтому каждому сервису я выделяю свой регламент в несколько страниц. Причём общие правила управления сопровождением согласно ITSM выносятся в такие регламенты, как «Управление инцидентами», «Управление изменениями» и т. д.

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

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

Вообще в любой работе я использую правило «Step by step, right on time», т. е. все делать поэтапно — шаг за шагом, причем каждый следующий шаг должен быть совершён в нужное время.

Кто задействуется в разработке каталога услуг? Должны ли в его создании принимать участие бизнес-пользователи и руководство?

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

Руководство компании тоже хорошо было бы задействовать. Бизнесу важно получать «за меньшие деньги бо’льшие результаты». Всегда есть соблазн сократить издержки, связанные с ИТ, но мы должны понимать степень влияния этих сокращений на качество сервисов. В этой работе CIO должен очень тесно взаимодействовать с бизнесом, но, как показывает практика, хотя бизнесу данный документ и нужен, однако он не готов активно участвовать в его разработке. На многих предприятиях бизнес-цели зачастую размыты, и говорить о том, что при разработке каталога сервисов мы должны подстраиваться под них, довольно сложно. Наконец, могут очень помочь и консультанты. Создание каталога услуг сродни написанию ИТ-стратегии. Инициатором в обоих случаях может быть и бизнес, а исполнителем в итоге все равно оказывается ИТ-служба. И тогда возникают сложности в согласовании полученного результата с бизнесом, так как он может предположить, что ИТ-служба «подгоняет документ под себя». Консультант же является исполнителем, и бизнесу очень часто легче принять те решения и предложения, которые ему предоставляет сторонний человек. Поэтому если есть возможность, то начинать надо с привлечения ИТ-консультантов, которые помогут создать каталог услуг. В качестве бонуса от них можно получить и помощь в создании ИТ-службы (или в ее реорганизации под процессную модель управления).

Какова структура описания сер­виса?

Есть разные мнения по поводу того, какие характеристики и сколько их должно быть у сервиса. Один консультант как-то сказал мне: «У каждого объекта существует бесконечное число характеристик, и исследователю нужно выделить самые важные и необходимые. Их должно быть не более десяти». В итоге мы остановились на следующем перечне характеристик услуги в каталоге:

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

Необходимо помнить, что время предоставления услуги может отличаться от времени ее сопровождения. Еще важнее выделять гарантированное время восстановления услуги после сбоя. Обычно бизнес говорит: «Есть только время сопровождения, в течение которого вы должны восстанавливать услугу практически сразу после сбоя». Но, например, у меня есть SLA с провайдером связи, и я не смогу восстановить её быстрее, чем оговорено в соглашении, так как мой сервис «Связь» зависит от него.

А какова структура самого ката­лога?

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

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

Вы упомянули о создании базы знаний на третьем этапе. Расскажите об этом...

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

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

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

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