Всем привет, меня зовут Марат Гайфуллин, я инженер-эксперт Дирекции надежности и автоматизации ИТ-процессов в банке «Уралсиб». В профессиональной деятельности работаю с подрядчиками и вендорами. Своими наработками и опытом поделился с коллегами в нашем профсообществе – в Гильдии SUPPORT тема вызвала большой интерес. Именно это и навело меня на мысль написать эту статью. Пояснение, в дальнейшем используется термин менеджер сервиса- это сотрудник ИТ, который отвечает за работоспособность и надежность сервиса, и за взаимодействие с вендором для этих же целей. Менеджер сервиса не заменяет юриста и договорной отдел, его задача проверить, что договор можно реально использовать во время проблем и аварий на ИТ сервисе. Сразу оговорюсь, материал не является юридической консультацией — рассматриваю вопрос, как технический специалист, с позиции эксплуатации и надежности.
Гильдия – это сообщество сотрудников, объединённых общими профессиональными интересами, навыками или задачами и созданная для обмена знаниями, опытом и лучшими практиками, а также для совместного решения профессиональных задач и развития компетенций.
Представьте, что вы читаете договор с подрядчиком.
На какие пункты в первую очередь обратите внимание? Предлагаю сверить ваши варианты и гипотезы из чата нашей встречи:
-
Ответственность сторон
-
Сроки и меры за нарушения
-
Условия расторжения
-
Стоимость (спойлер: это тема вне зоны компетенции менеджера сервиса)
А теперь я расскажу, на что важно обращать внимание менеджеру сервиса в работе с вендором, основываясь на своей практике:
1. SLA и приоритеты вендора в трех кейсах
Кейс 1. На моей практике, по зарубежным программным решениям, поддержку которых осуществляют отечественные подрядчики, обычно было так, что в срок SLA нам зачастую гарантируется только обходное решение, а на постоянное решение SLA не распространяется. Принимать такие условия или нет зависит от критичности сервиса, стоимости простоя из-за аварии и многих других факторов ИТ-ландшафта.
Кейс 2: В договоре поддержки от вендора фигурируют несколько позиций ПО – часть из них была внутренней разработкой подрядчика, другая часть разработки третьей компании. По всем пунктам доработки ПО срок не был установлен. В этом кейсе мы добились пересмотра договора в пользу установления SLA по собственным разработкам вендора. В целом очень рекомендую, если взаимодействуете с производителям ПО, требовать добавить в договор сроки доработки ПО.
Кейс 3: Подрядчик использует OpenSource-решения, например Redis или Nginx, ссылаясь на это нам не гарантируется оперативная доработка и какие-либо гарантии по срокам, если сбоит этот Open Source софт. Наша позиция — производитель полностью отвечает за свое ПО, включая его опенсорсные части, так как он сам их выбрал для включения в свое решение. В целом, лучше заранее зафиксировать ответственность поставщика за выбранные им компоненты, включая open source-зависимости
2. Меры за нарушения и что с ними делать
Формальные рычаги всем известны – это пени, неустойки и даже пересмотр периодических платежей. Почти всегда штрафы — это единственный действенный метод со стороны менеджера сервиса как-то повлиять на подрядчика.
Надо помнить, что сама возможность применить этот рычаг должна быть прописана в договоре. Однажды коллеги попросили меня помочь оформить претензионное письмо за нарушение сроков решения кейсов со стороны внешнего подрядчика. При изучении договора выяснилось, что сроки и ответственность за просрочку не прописаны. Это пример очень плохого договора, но даже из такой ситуации есть выход, вернемся к нему в статье чуть позже.
3. Претензионная работа
Отмечу, что претензионная работа — это важный формальный инструмент, но лучше, когда до неё не доходит. На практике гораздо эффективнее заранее выстроить регулярное взаимодействие с подрядчиком: проводить рабочие встречи, обсуждать проблемные зоны, фиксировать договоренности, держать понятный канал эскалации и поддерживать контакт не только с исполнителями, но и с руководством компании. Такая коммуникация помогает быстрее решать спорные вопросы, снижает количество просрочек и часто работает лучше, чем претензия, направленная уже после накопления проблем.
До написания претензии мы встречаемся с сотрудниками и менеджером подрядчика, где фиксируем нарушение договорных обязательств и запрашиваем план корректирующих действий. Если это не помогло – переводим коммуникацию в деловую плоскость.
При написании претензии не надо боятся, что вы испортите отношения с представителями подрядчика – это просто часть рабочего процесса для обеих сторон.
Нельзя скатываться в оскорбления и прочие проявления негативных эмоций. Задача претензионного письма четко обозначить случившийся факт и наметить дальнейшие шаги по решению кейса.
Формулировка претензии: Нарушены сроки по кейсу высокого приоритета. Рассчитайте пени по количеству дней просрочки и укажите плановый срок решения проблемы.
Иногда, претензионная работа – основной инструмент менеджера сервиса, если что-то идет не так. И вот почему:
-
На операционном уровне мы чаще всего взаимодействуем с исполнителями и менеджерами вендора. Нарушения сроков могут возникать по разным причинам: из-за внутренних приоритетов, нехватки ресурсов или ошибок в коммуникации. Если в договоре не прописан порядок действий при просрочке, претензия помогает официально зафиксировать проблему и донести её до руководства подрядчика, которое может и не знать о проблеме
-
Это ответственность менеджера сервиса – документировать проблемные ситуации и реагировать на них.
В поддержку этого пункта есть кейс из практики:
Подрядчик длительно решал проблему своего ПО. После решения проблемы он написал письмо бизнес-владельцу сервиса, в котором указал, что причина задержки была в команде поддержки сервиса со стороны команды ИТ заказчика. Бизнес пришел к руководству ИТ и попросил прокомментировать ситуацию с командой поддержки. После сбора всей переписки и артефактов инцидента, выяснилось, что команда поддержки заказчика работала оперативно, менеджер сервиса своевременно оформил претензионное письмо и позиция вендора стала несостоятельной. В претензии был запрос на перерасчет стоимости услуг, с которым вендор согласился.Претензии с команды поддержки сняты, а с вендором прошел серьезный разговор и ситуация больше не повторялась.
Именно наличие претензионного письма позволило закрыть вопрос.
4. Сроки расторжения договора и способы оплаты
На старте работ с новым вендором мы хотим работать долго и счастливо, но порой череда неприятных событий может привести к расторжению договора и поэтому этот пункт нужно внимательно изучить еще на старте заключения.
Первое, на что обратить внимание – это сроки уведомления о расторжении. Например, в договоре указано, что уведомление о расторжении должно поступить за 30 дней до окончания срока квартала. Тут могут быть и другие варианты, изучайте договоры со своими подрядчиками. Оформляйте все документы с оплатой после закрытия акта выполненных работ. Это дает дополнительную мотивацию для вендора выполнять все условия.
Чек-лист менеджера сервиса перед подписанием или при работе с существующим договором:
-
что считается инцидентом, запросом, консультацией и доработкой;
-
с какого момента стартует SLA;
-
прописаны ли реакция, обходное решение и постоянное решение;
-
есть ли SLA на доработки собственного ПО вендора, ответственность за компоненты третьих сторон и open source;
-
как фиксируются обращения;
-
определен ли порядок эскалации;
-
как считается просрочка;
-
какие последствия предусмотрены при нарушении сроков и обязательств;
-
как происходит расторжение и передача знаний.
Вот такие пункты в работе с вендором получились из моей практики. Если вам есть, что добавить буду рад добавить в личную базу знаний. 😊
ссылка на оригинал статьи https://habr.com/ru/articles/1042586/