В соглашениях об уровне обслуживания (Service Level Agreement, SLA) регламентируется ожидаемый уровень результативности работы поставщика услуг. При аутсорсинге разработки и сопровождения приложений само по себе SLA успеха не гарантирует, но является одним из многих инструментов по управлению взаимоотношениями с поставщиком услуг.

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

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

Насколько важны SLA для сделок разработки и сопровождения приложений?

Стоит иметь в виду, что SLA, хотя и помогают управлять предоставлением услуг, не заменяют стратегическое руководство отношениями с поставщиком в целом и не отменяют ответственности заказчика за установление архитектурных стандартов, политик и приоритетов.

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

Важно, чтобы пользователи услуг аутсорсинга рассматривали SLA как «живой» документ, эволюционирующий на всем протяжении сотрудничества

Чтобы выполнять SLA, поставщик услуг добавляет необходимые ресурсы и инвестирует в более оптимальные процессы и инструменты, как того требует соглашение. Без верно составленных SLA качество предоставляемых ресурсов может быть заметно хуже, а оптимизации процессов не будет.

Какие ошибки совершают заказчики при составлении SLA для разработки и сопровождения приложений?

Полноценное SLA включает в себя контролируемые параметры с указанием желательных и опасно низких уровней и – как правило – протокол добавления и исключения показателей. Важно, чтобы пользователи услуг рассматривали SLA как «живой» документ, эволюционирующий на всем протяжении сотрудничества.

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

Стивен Кирц, управляющий директор по трансформации бизнеса, Pace Harmon

На что заказчику нужно обращать внимание при подготовке содержания SLA для долгосрочного сотрудничества с учетом сложностей, характерных для разработки и сопровождения приложений?

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

Во-первых, отмечу, что в случае найма временных сотрудников вполне реально использовать SLA. Процесс доукомплектации персонала поставщиком услуг можно и нужно регулировать с помощью SLA – например, надо контролировать время, уходящее на введение новых специалистов в курс дела, и текучку персонала.

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

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

Какие виды эффективных SLA для разработки и сопровождения приложений можно порекомендовать ИТ-руководителю?

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

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

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

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

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

Основные проблемные области при составлении SLA

Согласование с бизнесом

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

Earnback

Earnback – избавление от штрафа, когда поставщик услуг после невыполнения SLA в течение какого-то промежутка времени обеспечивает более высокое качество обслуживания, чем было оговорено. Поставщики услуг нередко убеждают заказчиков в том, что прощать штрафы в обмен на улучшение обслуживания – это «справедливо», или соглашаются на более строгое SLA при условии наличия механизма earnback. Но нужно иметь в виду, что, отменяя штрафы, заказчик уменьшает стимулы, заставляющие поставщика улучшать ресурсы и процессы, то есть делать то, ради чего SLA заключаются в первую очередь.

Невозможность измерить контрольные параметры соглашения

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

Невозможность проверить показатели

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

Формулировка SLA

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

SLA, которые никогда не выполнялись

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

Контроль исключений

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

– Stephanie Overby. How to build better SLAs for more strategic applications outsourcing. CIO. August 21, 2015