SLA — новая ступень эволюции ИТ
28.01.2010
Использование ИТ-аутсорсинга и его глубокая интеграция в управление ИТ и все остальные бизнес-процессы заказчика приводит к необходимости четко фиксировать договоренности сторон, качество и объемы предоставляемых услуг, сроки, цели сотрудничества, продолжительность и экономическую эффективность, условия оплаты и расторжения, гарантии, размеры и формы компенсаций и пр.
Основным и единственным инструментом для регулирования вопросов предоставления качества ИТ-услуг на данный момент является SLA (Service Level Agreement — контракт, регламентирующий отношения между сервис-провайдером и его клиентом).
SLA — новая ступень эволюции ИТ
На определенном этапе развития любой организации и ее информационной системы перед теми, кто принимает решения, возникает дилемма. Как поддерживать работоспособность бизнеса?
Есть два варианта — собственными силами, то есть путем увеличения затрат на не профильную деятельность, либо привлекать для этих функций сторонние организации, специализирующиеся ИТ-аутсорсинге.
До недавнего времени выбор делался в сторону внутренних ресурсов, однако с развитием потребностей современного бизнеса не только средние, но и довольно крупные компании в последнее время исчерпывают собственные резервы для поддержания функциональности ИТ систем.
В этой связи резкое увеличение рынка аутсорсинга и оптимистичные прогнозы его развития являются закономерными. Кроме того, определенные сложности для внутренних ресурсов создает возникновение все новых и новых проектов в ИТ-сфере.
При передаче на аутсорсинг все больших объемов ИТ услуг необходима четкая схема взаимоотношений между организациями, предоставляющими информационные услуги, и потребителями этих услуг. На сцену выходит необходимость регулирования таких вопросов путем соглашений на ;предоставление услуг с должным качеством. Подобная практика получила емкое и исчерпывающее название — Service Level Agreement (SLA). Содержание термина SLA довольно четко раскрыто в нем самом.
SLA — это контракт, регламентирующий отношения между сервис-провайдером и его клиентом. Степень важности этого документа предполагает должные усилия для его грамотной разработки.
Какие ошибки чаще всего допускают руководители как заказчика так и исполнителя при работе с SLA.
Ошибки при работе с SLA
1. Не нужно никакого SLA.
SLA — это правообразующий документ. Именно в нем закреплено партнерство аутсорсиноговой компании и заказчика услуг. Его нельзя игнорировать ни в коем случае. На данный момент не существует стандартных норм и устоявшихся отечественных обычаев делового оборота для регулирования качества предоставляемых информационных сервисов. Поэтому SLA — единственный путь для установления взаимных прав, обязанностей, гарантий и компенсаций.
2. SLA просто описывает предоставляемые услуги.
Описание услуг — основной предмет SLA, что вполне естественно. Любая продуктивная совместная работа возможна при наличии общего языка. Именно при составлении SLA компании согласовывают общую терминологию.
Помимо указания на то, что и кому предоставляется, четко составленный SLA содержит множество важнейших подразделов: цель сотрудничества, его продолжительность, график предоставления услуг, условия оплаты, условия расторжения, гарантии, размеры компенсаций. SLA — основной и единственный инструмент для регулирования вопросов в сфере предоставления ИТ-услуг.
3. В SLA не должны быть указаны бизнес-цели клиента.
Это не совсем так. Всеобъемлющее понимание основных приоритетов в бизнесе потребителя дает организации, предоставляющей услуги, четкие ориентиры — каким образом нужно действовать при возникновении проблем с обслуживанием «этого» клиента.
4. Оплата производится за предоставленные услуги.
В определении цены при составлении SLA важнейший фактор — не сама услуга, а качество ее предоставления. Размер оплаты рассчитывается лишь исходя из определенных качественных критериев, таких, как доступность, время, требуемое для устранения сбоев и т. д.
Например, компания аутсорсер, может указать в своих SLA, что она компенсирует каждый час простоя бизнес сервисов и отсутствие доступа к ресурсам клиентов одним днем бесплатного обслуживания и так — вплоть до месяца бесплатного обслуживания в год.
5. Все провайдеры предоставляют стандартные SLA.
Это правда — некоторые даже уделяют место универсальности договорной базы в своей маркетинговой стратегии. Однако подавляющее большинство провайдеров идет навстречу пожеланиям пользователей, особенно корпоративных.
При работе с различными организациями не может идти речи о шаблонном SLA. Каждый SLA строится вокруг бизнес-требований конкретного клиента. Нельзя навязывать SLA пользователю, необходимо внести туда все, что ему необходимо».
6. Качество предоставляемых услуг невозможно измерить.
Пожалуй, — это главное заблуждение относительно SLA. В зависимости от типа услуги, потребители могут измерить качество ее предоставления по одному из параметров: доступность; среднее количество сбоев за определенный период, их динамика; время, затрачиваемое на их устранение.
В настоящее время целым рядом экспертных организаций по всему миру разрабатываются унифицированные системы материальной оценки качества услуг в сфере ИТ.
7. Условия SLA распространяются только на того, кто его подписывает.
В случае с пользователем — абсолютно верно. В случае с сервис-провайдером — нет, поскольку он, как правило, является лишь звеном целой инфраструктуры организаций, предоставляющих ИТ-услуги. Качество работы одного провайдера зависит от работы многих других. Часто имеют место SLA внутри подобных структур, они учитывают интересы конечных пользователей. Однако в любом случае SLA должен содержать пункт об ответственности за ущерб, нанесенный третьими лицами.
Модель SLA
Из всего многообразия возможных ИТ-сервисов, для предоставления или получения которых необходимо SLA, довольно сложно выделить универсальный каркас соглашения. Так называемая «рыба» здесь просто не работает вследствие огромного разнообразия требований и пожеланий потребителей ИТ-услуг. Тем не менее, существуют основополагающие принципы составления SLA — то, что должно обязательно присутствовать в этом документе.
В SLA необходимо четко и однозначно определить:
содержание предоставляемого сервиса
стороны соглашения
сроки действия.
условия ответственности сторон.
Важный элемент SLA — регламент доступности сервиса:
время работы сервиса, время потраченное на тестирование, текущую поддержку, модернизацию и т. д.
число конечных пользователей услуги — к примеру, 100 работников офиса, 10 тысяч посетителей сайта.
описывается обслуживаемое или задействованное в обслуживании оборудование.
Алгоритм предоставления услуги оговаривается следующим образом:
детально описываются процедуры мониторинга
устанавливается график отчетности о сервисе и
устанавливается график отчетности об неполадках и методах их устранения
указываются способы модернизации и эволюции сервиса, если его предоставление рассчитано на длительный срок или планируется существенное улучшение его качества.
Определяются спецификации уровней качества услуг:
средняя доступность, выраженная как среднее число сбоев на период предоставления сервиса
минимальная доступность для каждого пользователя
среднее время отклика сервиса
максимальное время отклика для каждого пользователя
средняя пропускная способность
описания расчета приведенных выше метрик
частота уведомлений о проделанной работе.
Части SLA касающиеся финансово-юридического урегулирования сотрудничества:
описание платежей, связанных с сервисом (возможно, как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса).
определяется ответственность заказчиков при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, ПО или изменения только в соответствии с описанной процедурой изменения).
процесс улучшения SLA. Определение SLA как особого сервиса позволяет сконфигурировать аппаратное обеспечение и ПО так, чтобы они максимально удовлетворяли потребностям сторон, изложенным в SLA.
Данная модель не является обязательной, а тем более исчерпывающей. При разработке SLA следует максимально ориентироваться на ситуацию сложившеюся в компании заказчика услуг.
Принципы составления SLA
Первый принцип: Требуйте только то, что нужно именно вам.
Например, основная деятельность компании напрямую зависит от веб-сайта. Поддержка его функционирования осуществляется сторонними организациями. В этом случае затраты на стопроцентную доступность составляют на порядок большие суммы, чем средства, направленные на поддержание 98% или даже 99% от его теоретической работоспособности. Следует сопоставлять качество услуг, предлагаемое сервис-провайдерами в SLA, в соответствии с реальными потребностями бизнеса. Быть может, услуг с меньшей стоимостью поддержки их качества будет вполне достаточно? Тогда не потребуется ассигновать в два-три раза большие средства.
Второй принцип: Уделяйте внимание защите важных компонентов.
Допустим, аутсорсинговая компания обеспечивает поддержку доступа к 5 вашим серверам, но SLA предусматривает компенсацию лишь в случае падения среднего уровня доступности ниже оговоренного показателя. Тем временем на деле стопроцентная работоспособность обеспечена четырем серверам из 5: всем, за исключением самого важного. Усредненные показатели хороши лишь в том случае, когда отсутствуют критические узлы, сбои которых не позволяют функционировать всей системе целиком. При наличии критических компонентов аутсорсеру невыгодно уделять отдельное внимание подобным ключевым участкам без дополнительной оплаты и описания в SLA данного момента. Следует отдельно описывать обслуживание первостепенных частей и всех остальных.
Третий принцип: Четко определите термины.
В любом SLA должен иметься список определений для понятий, относящихся к качеству сервиса. Краеугольным камнем является схема осуществления мониторинга: как будет отслеживаться качество услуг, как будет осуществляться переход на его новые уровни, как и в какой форме провайдер будет отчитываться.
Четвертый принцип: Учитывайте наилучшие и наихудшие сценарии развития событий.
Здесь показателен пример с аутсорсингом телефонной службы поддержки пользователей. SLA предполагает, что на 90% звонков будет дан ответ в течение 30 секунд. Это означает, что сотрудники help-desk смело могут заставить оставшиеся 10% пользователей ожидать помощи неопределенное время. Решением в подобных ситуациях станет видоизменение соответствующего пункта SLA. Проблема будут решена, если записать: «Провайдер гарантирует заказчику, что на 90% звонков, поступивших в службу поддержки, будет дан ответ в течение 30 секунд; на оставшиеся 10% — ответ будет дан не позднее 60 секунд».
Пятый принцип: Компенсация должна быть адекватной.
Бизнес, уничтоженный низким качеством технологического обслуживания либо плохим обеспечением безопасности, уже не нуждается в лишнем годе бесплатного сервиса в качестве компенсации. Здесь потребуется прямое возмещение материальных убытков, а не удешевление и без того некачественных услуг. Компенсация должна соответствовать причиненному ущербу.
Шестой принцип: Обязательная модернизация.
Условия долгосрочных SLA должны периодически пересматриваться в зависимости от условий диктуемых ситуацией на рынке ИТ услуг, а так же от спецификаций оборудования используемого для предоставления сервисов.
Главный принцип: Творческий поход обеих сторон
Удачное, работоспособное SLA — это соглашение, над которым плодотворно потрудились и компания, предоставляющая услуги, и потребитель этих услуг. Когда такой процесс действительно имел место, SLA, по большому счету, может смело храниться в архиве, поскольку на этой стадии люди уже прекрасно знают, как им сотрудничать друг с другом, на чем базировать и как развивать партнерские отношения. А это и есть основная цель SLA.
Источник www.b-itm.ru
Возврат к списку