Приятно, что моя статья может пригодиться кому-либо еще. Мы обычно запрашиваем проект договора у самого подрядчика. Далее проект проходит цепочку согласований у большого количества служб( ИТ, Инфобез, Договорной отдел, Юридический отдел и тд) , где каждый может указать замечания, которые в дальнейшем с подрядчиком прорабатываются. Могут быть поправлены формулировки, что-то добавлено или наоборот удалено. В целом по вопросу, считаю, что если клиент не сразу предъявляет свои условия, а сначала спрашивает , что ему могут предложить (запрос проекта договора у вендора, например) , то вероятность получить более выгодное предложение выше. Но, тут опять же, если речь про начинающего менеджера ИТ сервиса ,ему было бы гораздо проще, если бы был типовой договор, где описаны основные моменты , которым надо следовать.
Добрый день! В статье я больше сфокусировался на договорах поддержки.Довелось видеть разные договора. В каких-то, как Вы правильно заметили, только реакция прописана. Но, думаю, это как раз пример не очень хорошего договора, потому что внешняя поддержка может отреагировать сразу после открытия к ним тикета словами "кейс увидели взяли в работу". А нам важно, когда будет предоставлено ,как минимум, обходное решение. Особенно критично, если случился сбой на ПО, которое нужно для обслуживания клиентов. В таком случае приоритет задачи или инцидента считается наивысшим и нам нужно , чтобы в гарантированный срок было предоставлено любое решение от внешнего подрядчика, которое восстановит работоспособность - обычно в пределах максимум нескольких часов. По низкому приоритету срок решения вообще может быть не прописан или прописан длительный, например, несколько месяцев. Для команды поддержки очень важно, чтобы в договоре с внешним подрядчиком были прописаны сроки решения инцидентов. Но если прописать только один срок решения на все инциденты - договор выйдет очень дорогой. Отсюда и возникает деление на приоритеты , в зависимости от которых гарантируется срок решения. В идеале, правильно определенные приоритеты инцидентов, прописанные в договоре, позволят клиенту не переплачивать и получать заказанный уровень сервиса, а внешнему подрядчику оптимально запланировать свои трудозатраты, например, сколько сотрудников выделить под того или иного клиента, какого уровня компетенций и тд.
Приятно, что моя статья может пригодиться кому-либо еще. Мы обычно запрашиваем проект договора у самого подрядчика. Далее проект проходит цепочку согласований у большого количества служб( ИТ, Инфобез, Договорной отдел, Юридический отдел и тд) , где каждый может указать замечания, которые в дальнейшем с подрядчиком прорабатываются. Могут быть поправлены формулировки, что-то добавлено или наоборот удалено. В целом по вопросу, считаю, что если клиент не сразу предъявляет свои условия, а сначала спрашивает , что ему могут предложить (запрос проекта договора у вендора, например) , то вероятность получить более выгодное предложение выше. Но, тут опять же, если речь про начинающего менеджера ИТ сервиса ,ему было бы гораздо проще, если бы был типовой договор, где описаны основные моменты , которым надо следовать.
Добрый день! В статье я больше сфокусировался на договорах поддержки.Довелось видеть разные договора. В каких-то, как Вы правильно заметили, только реакция прописана. Но, думаю, это как раз пример не очень хорошего договора, потому что внешняя поддержка может отреагировать сразу после открытия к ним тикета словами "кейс увидели взяли в работу". А нам важно, когда будет предоставлено ,как минимум, обходное решение. Особенно критично, если случился сбой на ПО, которое нужно для обслуживания клиентов. В таком случае приоритет задачи или инцидента считается наивысшим и нам нужно , чтобы в гарантированный срок было предоставлено любое решение от внешнего подрядчика, которое восстановит работоспособность - обычно в пределах максимум нескольких часов. По низкому приоритету срок решения вообще может быть не прописан или прописан длительный, например, несколько месяцев. Для команды поддержки очень важно, чтобы в договоре с внешним подрядчиком были прописаны сроки решения инцидентов. Но если прописать только один срок решения на все инциденты - договор выйдет очень дорогой. Отсюда и возникает деление на приоритеты , в зависимости от которых гарантируется срок решения. В идеале, правильно определенные приоритеты инцидентов, прописанные в договоре, позволят клиенту не переплачивать и получать заказанный уровень сервиса, а внешнему подрядчику оптимально запланировать свои трудозатраты, например, сколько сотрудников выделить под того или иного клиента, какого уровня компетенций и тд.