Компании обращаются к услугам ИТ аутсорсинга по разным причинам и с целью достижения различных целей. Вне зависимости от того, хочет ли компания получить экспертизу в какой-то редкой области, или уменьшить расходы, снять избыточную нагрузку со своих технических специалистов или увеличить управляемость каким-либо из ИТ-сервисов, аутсорсинг может помочь в любом из этих вопросов. Аутсорсинговые отношения между поставщиком и получателем ИТ услуг носят стратегический характер и на протяжении многих лет регулируются в рамках заключенного между ними аутсорсингового договора. С целью контролировать предоставление услуг и их качество на протяжении всего этого периода, между поставщиком и потребителем услуг устанавливается соглашение об уровне обслуживания (Service Level Agreement (SLA)).

Соглашение об уровне обслуживания (SLA) является неотъемлемой частью любого аутсорсингового договора. Оно определяет границы проекта с точки зрения функций и услуг, которые поставщик услуг должен предоставить клиенту, допустимые объем работы, и приемлемые критерии по оперативности работы и конечным результатам.

В основе эффективного SLA лежат показатели производительности. В течении всего срока действия аутсорсингового договора, эти метрики будут использоваться для определения эффективности работы поставщика услуг и определения, выполняет ли поставщик услуг свои обязательства. Правильно выбранные и примененные метрики SLA:

• Измеряют нужные характеристики производительности с целью удостовериться, что клиент получает услуги с требуемым уровнем качества, а поставщик услуг достигает необходимого уровня рентабельности.
  
• Могут быть легко собраны с надлежащим уровнем детализации, но без огромных накладных расходов, и
  
• Связывают все обязательства в разумный и достижимый уровень производительности так, что “хороший” сервис можно легко отличить от “плохого”, предоставляя возможность поставщику услуг удовлетворить все потребности клиента.

Пять принципов для формирования соглашения об уровне обслуживания:

1. Измеряйте то, что мотивирует правильное поведение.

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

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

При выборе метрики, в первую очередь обратите внимание на поведение, которое вы хотите мотивировать. Какие факторы наиболее важны для вашей организации? Сокращение затрат и/или количества брака? Уменьшение времени реакции на обращение или скорость устранения инцидентов? Какими факторами вы готовы пожертвовать, ради достижения цели? Выберите исходный набор метрик, которые могут характеризовать нужное вам поведение.

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

2. Обеспечьте, чтобы метрики отражали факторы, которые находятся вне вашей зоны контроля.

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

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

3. Выберите метрики, которые легко собирать.

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

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

4. Лучше меньше да лучше.

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

5. Определите реалистичный базовый уровень качества обслуживания.

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

Рассмотрим клиента, который выбирает поставщика услуг ИТ аутсорсинга для обслуживания своей компаний. Одной из важнейших целей клиента является обеспечение бесперебойной работы компьютерной сети и информационных сервисов. Естественно, было бы заманчиво установить такую метрику, что поставщик ИТ услуг обязан обеспечить функционирование информационных сервисов всегда: 24 часа в сутки, 7 дней в неделю, 365 дней в году и не допускает возникновения сбоев. Сколько будет стоить такой сервис, если такой сервис вообще возможно предоставить? Взгляните на вещи более реалистично: компания не работает ночью и в выходные и вполне может пережить перерыв в сервисе в это время для проведения профилактического обслуживания. Сбой в дневное время – это, конечно, критично, но если это сбой происходит не чаще одного раза в полгода, то бизнес может пережить до 4-х часов простоя. Бизнесу достаточно доступности информационных сервисов на уровне 99,8%, т.к. это не приведет к потерям и не потребует сильных инвестиций в ИТ и такой сервис можно получить за разумную цену.

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