Как успешно внедрить Соглашение об Уровнях Сервиса

Соглашение об Уровнях Сервиса (SLA) является одним из самых важных – если не основным – элементом Сервис Менеджмента ИТ.

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

А это и есть основная цель ИТ Сервис Менеджмента (ITSM).

»Хорошее соглашение может многое. Оно сократит излишние расходы, как денежные так и операционные», — говорит Рик Штурм, президент Корпорации по Производственному Менеджменту – аналитико-исследовательской фирмы, расположенной в Боулдере, штат Колорадо. »Вы, конечно, можете сделать его сложным, но он не обязательно должен быть таковым. SLA не должен походить на телефонную книгу Манхэттена. Он должен быть коротким и содержательным и описывать одну услугу, а также иметь метрики в соответствии с опытом пользователей.»

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

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

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

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

С чего начать

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

Попробуем описать первые шаги на этом тернистом пути:

  • Разберитесь с тем, что у вас есть – Штурм предупреждает, что перед тем, как заводить разговоры об SLA, администраторы ИТ должны провести инвентаризацию имеющихся у них ресурсов. Это означает, что они должны убедиться в своей способности управлять сервисами, которые уже предлагает ИТ. Не пытайтесь проводить совещание по SLA без соответствующих результатов измерений.

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

    Штурм предлагает администраторам попробовать измерить полное время решения проблемы. Это нелегко, но очень полезно иметь такой показатель под рукой.

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

  • Продумайте все заранее – Патриция Брамхал, президент консультационной компании Тидак, расположенной в Калифорнии, советует руководителям ИТ все серьезно продумать, прежде чем углубляться в процесс.

    »Продумайте конечную цель», – пишет Патриция. »Подумайте о сотрудниках, которые у вас есть. Какого типа услуги вы можете оказывать и управлять? Продумайте все как следует.»

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

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

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

  • Принимайтесь за Первое Соглашение – Существуют разногласия между аналитиками и консультантами о том, каким должно быть первое соглашение. Некоторые рекомендуют приниматься за самую сложную проблему, которая есть в ИТ. Другие, между тем, советуют, что лучше начинать с чего-нибудь полегче, чтобы удача воодушевила вас.

    Шнайдер иногда рекомендует выбрать приложение или бизнес отдел, которые вызывают в компании больше всего проблем. Найдите их. Займитесь ими. Решите проблемы.

    «Найдите больное место бизнеса и сфокусируйтесь сначала на нем», — пишет Шнайдер. «Если у бизнеса есть больное место, то руководство будет радо вылечить его в первую очередь, и менеджеры с удовольствием будут работать с вами».

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

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

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

  • Сосредоточьтесь на целях бизнеса – Штурм также рекомендует ИТ акцентировать внимание на бизнесе во время любых переговоров. Не упоминайте о ваших проблемах. Покажите им данные, которые напрямую относятся к их работе. Поговорите о том, сколько заказов проходит через систему за восемь рабочих часов. Сравните с показателями за прошлый год, с показаниями пятилетней давности.

  • Не отрывайтесь от реальности – Брамхал отмечает, что очень важно придерживаться реальных возможностей во время переговоров.

    Начальник одного отдела может быть недоволен тем, что со времени запроса на новый компьютер до момента его установки проходит две недели. Менеджер, быть может, хочет, чтобы компьютер установили через два дня. Реально вы можете купить оборудование и установить его в течение недели. Скажите, что вы можете сократить период доставки, но что это будет стоить денег. Захотят ли они заплатить больше из своего бюджета, чтобы поскорее получить требуемое оборудование?

    Может быть, не захотят, и это прекратит лишнюю дискуссию.

  • Список приоритетов – Все не может быть самым главным. ИТ придется разработать с бизнес-менеджерами то, что называется иерархией приоритетов.

    Брэмхал советует ИТ менеджерам составить список всего, что они делают для каждого департамента. Когда бизнес руководитель начинает спорить, что ей нужен новый компьютер через два дня, напомните ей, что если ей нужен новый сотрудник, то надо настроить голосовую почту, и почтовый ящик. Этому сотруднику также надо будет провести тренинг по политике и правилам безопасности в компании.

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

  • Не принимайте вызов – Шнайдер предупреждает, что администратор ИТ не должен никогда созывать на митинг 10 бизнес менеджеров, а потом пытаться их всех вместе переубедить. «Если вы пойдете на митинг, где все против вас, то они будут поддерживать друг друга и получится хаос. Вам надо заранее поговорить с каждым индивидуально, чтобы привлечь их на свою сторону. Групповое собрание – это просто формальность».

    «На мой взгляд, это нормальный ход событий для любого мирного процесса», — добавляет он.

  • Всегда выполняйте обещания – И Брэмхал и Штурм в один голос говорят, что самая большая ошибка администраторов ИТ – это обещания, которые они не могут выполнить. Никогда не подписывайте соглашения, которые не можете выполнить.

    «Случается, конечно, всякое, и случается намеренно», — говорит Штурм. «В некоторых случаях пользователи пытаются уговорить ИТ подписаться на невозможное… Иногда ИТ просто устает от того, что висит над ними «домокловым мечом». Не обещать невозможного – это лекарство от несчастья».

    Подписание Соглашения об уровнях обслуживания – это большая работа, но результаты, по мнению Брэмхал, стоят затраченного времени и усилий.

    «Стоят, потому что появляется возможность контроля и возможность сказать: «Вот то, что мы делаем. Это та выгода, которую мы приносим компании», — говорит она. «Это также показывает, что вы не боитесь быть оцененными и проверенными. «Я сказал, что выполню услугу за этот период времени и я выполню» ИТ часто имеет плохую репутацию из-за того, что говорит, что выполнит что-то за определенное время, а потом не укладывается в указанный период, и тогда кажется, что ИТ никогда не выполнит поставленную перед ним задачу…»

    Sharon Gaudin, 13 марта 2006. Перевод Виталия Фролова
    URL: http://www.itsmwatch.com/itil/article.php/3591046

  • Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

    Комментарии закрыты.