«data-stats =» true «> Наиболее распространенные ошибки в SLA, которые допускают руководители Стефани Оверби, CIO Magazine, 03/12/2021 в 15:35 SLA Соглашение об ИТ-услугах Бизнес и менеджмент Поделиться Твитнуть LinkedIn

От рассмотрения SLA как разовой задачи до отказа от положений об ответственности ИТ-лидерам следует избегать этих ловушек при работе со своими партнерами по ИТ-услугам и облачным вычислениям для увеличения стоимости бизнеса.

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

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

См. также: HPE Green Lake для АНБ Что такое MSP? О стратегическом аутсорсинге ИТ-услуг

Пандемия COVID-19 также повысила ставки в управлении SLA. «SLA повышают согласованные уровни производительности, которые требуются, чтобы клиенты продолжали получать услуги, необходимые им для ведения своего бизнеса, независимо от местонахождения персонала клиента или поставщика, воздействия пандемии или способности потребителей покупать и/или или взаимодействовать «, — говорит Клэй Калхун, партнер ISG, компании, занимающейся исследованиями и консультированием в области технологий.

Поскольку многие ИТ-функции продолжают работать в распределенном режиме, SLA стали основным показателем производительности. «Новая реальность, вызванная COVID, увеличивает зависимость организации от достоверных данных для определения того, насколько хорошо (или плохо) работают операции», — говорит Дэвид Боровски, директор консалтинговой фирмы West Monroe по вопросам бизнеса и технологий.

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

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

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

1. Отсутствие согласия и предварительная договоренность об SLA.

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

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

2. Слишком много SLA

Слишком большое количество SLA может поставить под угрозу качество согласованных услуг. Например, если у клиента 65 соглашений об уровне обслуживания, а сумма риска составляет только 10% от ежемесячных выставленных счетов, нарушение одного из них приводит к проценту кредита на обслуживание поставщика в размере 1/65 от 10%. «Определение слишком большого количества SLA ослабляет влияние каждого и [затрудняет] поставщикам определение того, какие из них наиболее важны для определения приоритетов и активного управления», — говорит Боровски из West Monroe.

3. Непонимание сути точки зрения поставщиков

«Часто соглашение об уровне обслуживания ориентировано на время третьей стороны, но ИТ-руководитель может быть больше озабочен производительностью приложения или услуги, которые они предоставляют», — говорит Мартин из HFS Research.

Например, когда дело доходит до SLA для резервного копирования или аварийного восстановления, компании следует рассмотреть возможность явного документирования этого в контракте.

4. Разрозненные SLA

По словам Фуллера из Hackett Group, соглашения об уровне обслуживания, которые слишком сфокусированы на безотказной работе отдельных компонентов инфраструктуры и приложений, являются проблематичными. Джордан из TCS соглашается. «Все больше и больше организаций требуют интеграции услуг с производительностью бизнеса с точки зрения SLA. Затем на основе этих результатов получаются соответствующие показатели эффективности ИТ, и становится ясно, кто в экосистеме отвечает за поддержку отдельных бизнес-результатов », — говорит он.

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

5. Положения об отказе от участия

Они незаменимы в случае постоянных неудовлетворительных результатов или пропущенных целей. «Без ясности в контракте SLA ничего не стоит, — говорит Мартин из HFS Research. — Это должны быть четко определенные пороговые значения для количества« x »раз за период времени, и их следует регулярно пересматривать с поставщиком. «

6. Отсутствие ясности в расчетах SLA

«Я видел случаи, когда заказчик получал SLA от поставщика, и в их контракте говорилось, что только документация SLA поставщика считается фактической и точной, — говорит Мартин. — Это должно стать серьезной причиной для беспокойства любого руководителя. «.

7. Невозможно измерить

По словам Калхуна из ISG, ИТ-организации нередко устанавливают метрику производительности без надлежащих данных, показывающих цель. Однако отсутствие метода для надежного расчета SLA — четких, понятных и простых в использовании инструментов и процессов — обычно приводит к чрезмерно громоздкому управлению SLA, говорит Фуллер из Hackett Group.

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

8. Рассмотрение SLA как разового действия

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

9. Предполагая, что SLA не имеют значения в облаке

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

10. Безопасность не распространяется

Подумайте, какие текущие обязательства производитель берет на себя в отношении аварийного восстановления, шифрования, реагирования на инциденты или оценки уязвимости. «По возможности клиенты должны требовать от поставщиков услуг включения безопасности в свои SLA, — говорит Ален Паннетрат, старший научный сотрудник и менеджер по продукту Cloud Security Alliance.

11 Использование SLA в качестве Инструменты разрешения конфликтов

Ошибочно полагаться на контракт для решения проблемы, прежде чем копаться в ней глубже. «Первым шагом в любом конфликте должно быть понимание его последствий и попытка возмещения ущерба, а не сосредоточение внимания на том, кто виноват в контракте и какое наказание должно быть наложено», — говорит заместитель PMG. Дастин Хиллиард, технический директор eSentire, добавляет: «Важнее расставить приоритеты в отношениях с клиентами и их результатах, чем разбираться с техническими или эксплуатационными недоразумениями, которые изначально могли привести к конфликту».

12. Неспособность взять на себя ответственность

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

«Следовательно, организация должна рассмотреть вопрос о том, допускает ли зрелость ее внутренних процессов тот тип SLA, который был согласован, — говорит Ясин. — из-за незрелости организации».

13. Статические SLA

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

ИТ-лидерам также следует подумать о повышении производительности и лояльности по отношению к поставщикам. «Важно постепенно сужать ключевые показатели эффективности SLA с течением времени, — говорит Ясин. «Это мотивирует поставщиков к постоянному совершенствованию».

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

Для коммерческого воспроизведения контента Computerworld необходимо приобрести лицензию. Свяжитесь с нашим партнером YGS Group по адресу [email & # 160; protected] Поделиться Поделиться LinkedIn Tweet #hpe_special_offers.