Стефани Оверби

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

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

Именно поэтому важно составить SLA для сделок ИТ-аутсорсинга максимально правильно.

Составляя SLA, полагайтесь на здравый смысл

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

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

Не рассчитывайте, что неустойки помогут экономить

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

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

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

От положений об отработке можно отказаться

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

Следите, чтобы метрики не перекрывались

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

Следите за точностью

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

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

Не устанавливайте слишком высокую незащищенную часть оплаты

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

Предусмотрите льготный период

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

Не переплачивайте за повышенные уровни обслуживания

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

Вносите со временем коррективы в SLA

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

Не рассматривайте выполнение SLA как гарантию успеха

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

– Stephanie Overby. 10 do’s and don’ts for crafting more effective SLAs. CIO. May 30, 2018

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

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

Смена поставщика вместо устранения первопричин

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

Фокусировка на решениях, а не на проблемах

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

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

Заключение сделки в расчете на преобразования

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

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

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

Аутсорсинг «по шаблону»

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

Чрезмерно строгий контракт

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

Недооценка влияния на сотрудников

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

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

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

Недостаточное внимание переходному периоду

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

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

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

Недостаточные инвестиции в руководство

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

Управление с помощью соглашений об уровне сервиса

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

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

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

– Stephanie Overby. 9 IT outsourcing mistakes to avoid. CIO. MAR 7, 2018

Методологии agile-разработки программного обеспечения существуют уже достаточно давно, но устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.

«Традиционный подход к заключению соглашений предполагает, что команда разработки может с помощью подробного технического проекта определять, с каким уровнем конкретизации будет конечный продукт, – говорит Дерек Шаффнер, адвокат юридической конторы Mayer Brown. – Согласовываются и указываются основные вехи, условия приемки клиентом и сроки получения выплат. Все это легко отразить в соглашении о разработке, поскольку процесс разработки традиционно носит линейный характер и начинается с детального планирования, после которого идут проектирование, написание кода, тестирование и ввод в эксплуатацию».

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

Однако существуют контрактные механизмы, и заказчики могут ими воспользоваться, чтобы уменьшить неопределенность, сохранив преимущества agile-разработки с ее кооперативным характером. О том, какие меры предосторожности понадобятся, Шаффер рассказал в интервью CIO Magazine.

- В чем главные сложности при составлении контрактов на agile-разработки?

Для agile-разработки ПО характерно неструктурированное, непрерывное взаимодействие между клиентом и разработчиком, основанное на доверии и взаимопонимании, а это трудно формализовать в контракте. Наибольшие сложности связаны с созданием системы норм, которая позволит получить преимущества agile-разработки с ее творческим подходом и одновременно выполнить требования клиента о своевременном создании продукта по справедливой цене.

- Для agile-разработки сделку с фиксированной ценой заключить не удастся. Как рассчитать расценки при подготовке agile-контракта?

Для agile-разработки ПО больше подойдет контракт, предусматривающий оплату затраченного рабочего времени и материалов (time and materials, T&M), но такой вариант может не устроить финансовый отдел и ИТ-директора. Ведь agile-разработка требует доверия, поскольку нет четких требований, а модель T&M может спровоцировать разработчика брать деньги за максимально большее количество часов.

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

Модель T&M более привлекательна, поскольку в ней предусмотрены условия прекращения проекта, более дружественные для клиента. Но есть и большой риск: когда проект идет уже достаточно давно, желание клиента закончить его перевешивает легкую возможность выхода из соглашения. Из-за этого может возникнуть ситуация, когда разработчик начнет выманивать деньги из заказчика к концу проекта, если, конечно, нет лимита на выплаты.

- Как именно право на расторжение контракта работает в описанных ситуациях?

Учитывая, что цель каждой итерации – создать работоспособный код, за который оплата осуществляется по принципам T&M, как правило, договор позволяет клиенту прекратить проект в конце любой итерации, обычно без платы за аннулирование заказа. Если клиента не устраивает продукт, созданный за очередную итерацию, он просто может выйти из контракта. Вероятность того, что проект сильно отойдет от спецификаций за одну итерацию, минимальна, поскольку требования определяются в начале каждой итерации так, чтобы продвинуться к цели создания продукта в соответствии с общим замыслом.

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

- Agile-разработка по сути своей является изменчивой. Как заказчику предусмотреть в контракте какие-то вехи еще до начала работы?

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

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

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

- Как заказчику снизить риск текучки сотрудников на проектах, требующих непрерывной работы?

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

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

- При традиционном аутсорсинге разработки приложений поставщик услуг на определенное время дает гарантию того, что продукт будет работать согласно требованиям и любое несоответствие им будет устранено. Можно ли получить такие гарантии при agile-разработке?

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

- Как обговорить права на интеллектуальную собственность с учетом того, что agile-разработка подразумевает активное взаимодействие клиента и поставщика услуг?

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

- Если клиент тратит слишком много усилий на составление соглашения об agile-разработке, может ему не стоит передавать такую разработку вовне?

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

– Stephanie Overby. How to contract for outsourcing agile development. CIO. July 1, 2016

В соглашениях об уровне обслуживания (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 стоит включить управление сроками анализа первопричин сбоев, а также ограничения на время выполнения синтетических транзакций и количество возобновленных заявок.

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

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

В 2014 году меньше 10% соглашений об услугах аренды приложений предусматривали выпуск по методам DevOps, выяснило исследование, проведенное компанией Everest Group, оказывающей консультации по аутсорсингу. Из этого следует, что на предприятиях пока не убеждены в том, что их аутсорсинг-партнеры могут серьезно помочь с внедрением новых методов выпуска, считает Югал Джоши, директор практики Everest Group.

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

Провайдеры с опытом интеграции услуг имеют больше всего шансов получить заказы на внедрение DevOps

«Заказчики пока что только разбираются, что такое DevOps, – продолжает Джоши. – Чтобы начать извлекать пользу из DevOps, нужно обеспечить координацию действий многих участников, а на типичном предприятии сделать это непросто. Эксперименты с DevOps проводят в рамках внутренних проектов и инициатив проверки концепции, причем чаще всего самостоятельно либо путем краткосрочного найма знающих людей – на роль скорее исполнителей, чем лидеров по проведению перемен».

Спрос на консультационные услуги по аренде приложений растет. Две из трех сделок на услуги аренды приложений, заключенных в 2014 году, предусматривали консалтинг, сообщают в Everest. А сам сегмент услуг аренды приложений в 2014 году вырос на 4%, тогда как общий рынок ИТ-услуг – на 3,4%.

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

Аутсорсинговые компании сами должны показывать свою компетенцию в сфере DevOps, прежде всего – свои возможности в области сквозной трансформации. «Учитывая, что большинство заказчиков пользуется услугами провайдеров для решения какого-то узкого круга задач, тем придется демонстрировать свои способности в других областях, – указывает Джоши. – Более того, надо показывать свою готовность взаимодействовать с другими сервис-провайдерами, чтобы достичь желаемого результата». Провайдеры с опытом интеграции услуг имеют больше всего шансов получить заказы на внедрение DevOps.

Что касается заказчиков, возможно, сейчас самое время прыгнуть в неизведанное и начать экспериментировать с аутсорсинг-партнерами, переводя на DevOps приложения с низким риском, чтобы выяснить, как лучше всего координировать деятельность разных сервис-провайдеров. «Здесь могут оказаться полезными уже установившиеся методы интеграции сервисов, – отмечает Джоши. – Заказчикам стоит понимать, что сервис-провайдер может сыграть важную роль в этом переходе, но общее управление переменами должно осуществляться собственными силами. На сервис-провайдеров эту задачу возлагать неразумно – слишком высок риск для бизнеса».

Stephanie Overby. IT customers slow to embrace outsourced DevOps. CIO (US). 08/07/2015