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

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

Представьте, что вы читаете договор с подрядчиком.

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

1. Ответственность сторон

2. Сроки и меры за нарушения

3. Условия расторжения

4. Стоимость (спойлер: это тема вне зоны компетенции менеджера сервиса)

А теперь я расскажу, на что важно обращать внимание менеджеру сервиса в работе с вендором, основываясь на своей практике:

1. SLA и приоритеты вендора в трех кейсах

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

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

Кейс 3: Подрядчик использует OpenSource‑решения, например Redis или Nginx, ссылаясь на это нам не гарантируется оперативная доработка и какие‑либо гарантии по срокам, если сбоит этот Open Source софт. Наша позиция — производитель полностью отвечает за свое ПО, включая его опенсорсные части, так как он сам их выбрал для включения в свое решение. В целом, лучше заранее зафиксировать ответственность поставщика за выбранные им компоненты, включая open source‑зависимости

2. Меры за нарушения и что с ними делать

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

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

3. Претензионная работа

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

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

При написании претензии не надо боятся, что вы испортите отношения с представителями подрядчика — это просто часть рабочего процесса для обеих сторон.

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

Формулировка претензии: Нарушены сроки по кейсу высокого приоритета. Рассчитайте пени по количеству дней просрочки и укажите плановый срок решения проблемы.

Иногда, претензионная работа — основной инструмент менеджера сервиса, если что‑то идет не так. И вот почему: 

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

• Это ответственность менеджера сервиса — документировать проблемные ситуации и реагировать на них.
  В поддержку этого пункта есть кейс из практики:
  Подрядчик длительно решал проблему своего ПО. После решения проблемы он написал письмо бизнес‑владельцу сервиса, в котором указал, что причина задержки была в команде поддержки сервиса со стороны команды ИТ заказчика. Бизнес пришел к руководству ИТ и попросил прокомментировать ситуацию с командой поддержки. После сбора всей переписки и артефактов инцидента, выяснилось, что команда поддержки заказчика работала оперативно, менеджер сервиса своевременно оформил претензионное письмо и позиция вендора стала несостоятельной. В претензии был запрос на перерасчет стоимости услуг, с которым вендор согласился.

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

  Именно наличие претензионного письма позволило закрыть вопрос.

4. Сроки расторжения договора и способы оплаты

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

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

Чек‑лист менеджера сервиса перед подписанием или при работе с существующим договором:

• что считается инцидентом, запросом, консультацией и доработкой;

• с какого момента стартует SLA;

• прописаны ли реакция, обходное решение и постоянное решение;

• есть ли SLA на доработки собственного ПО вендора, ответственность за компоненты третьих сторон и open source;

• как фиксируются обращения;

• определен ли порядок эскалации;

• как считается просрочка;

• какие последствия предусмотрены при нарушении сроков и обязательств;

• как происходит расторжение и передача знаний.

Вот такие пункты в работе с вендором получились из моей практики. Если вам есть, что добавить буду рад добавить в личную базу знаний. ?