Рубрикатор |
Блоги | Леонид АНИКИН |
Клиентам стоит требовать пересмотра цены каждый квартал
19 февраля 2018 |
Я часто встречаю клиентов, которые агрессивно снижают цены, давя на поставщиков. Я знал превосходных менеджеров по закупкам, которые добивались скидки в 50%. Несколько раз у меня были клиенты, которые даже нанимали специальных консультантов, которые должны были опустить цену в коммерческих предложениях, которые я делал.
В Облаках происходит тоже самое. Когда клиент ищет облачного провайдера, переговоры могут вестись с половиной игроков на рынке, а в тендере иногда бывает до 10 провайдеров. Клиенты пытаются торговаться относительно расписания платежей, тестового период, фиксировать курс доллара и ещё множество условий в договоре, пытаясь хотя бы немного ещё уменьшить сумму платежей.
И в конце, когда провайдер сдался и компромисс найден, клиент подписывает договор, получает ресурсы в Облаке и … полностью забывает о контракте.
Будучи провайдером, мы регулярно выходим сами к некоторым клиентам самостоятельно с предложением пересмотреть контракт и скорректировать некоторые цены вниз! Обычно, клиенты отслеживают актуальность своих облачных контрактов либо очень редко, либо никогда
Причина понятна. В стандартном процессе покупки участвуют технический эксперт и закупщик. Первый смотрит на параметры сервиса, а второй ведёт переговоры по условиям. Когда поставщик выбран и контракт подписан, то закупщик уходит со сцены, и технические специалисты остаются одни.
Однако в эру Облаков такая организация процесса неэффективна. Контракт на облако не имеет даты окончания и может длиться годами. Закупщики не приходят, и условия остаются прежними. На самом деле, есть большая группа параметров соглашения, которую стоит регулярно пересматривать:
· Твёрдый заказ и “Pay as you Go”. Большинство провайдеров (включая AWS и Azure) очень хотят гарантировать утилизацию их ресурсов посредством долгосрочных контрактов. И они готовы продавать ресурсы таким контрактам намного дешевле, чем по схеме “Pay as you Go”, когда клиент в любой момент может изменить количество ресурсов в любую сторону. Обычно, в начале использования Облака клиенту сложно сказать, какое количество ресурсов будет гарантированно использовано, но через какое-то время, заказчику уже довольно легко определить, что можно смело включить в твёрдый контракт, а где лучше оставить возможность отказаться в любой момент.
· SLA и штрафные санкции за его нарушение. Возможно, я удивлю вас, но многие провайдеры, действительно, относятся к SLA (гарантированным параметрам качества услуг) очень серьёзно. Именно поэтому провайдеры часто занимают негибкую позицию в переговорах относительно штрафных санкций за нарушения минимальных значений. Они не знают, как новый клиент будет использовать ресурсы в Облаке, какой тип приложений он туда перенесёт, и как хорошо они будут работать с инфраструктурой провайдера. Однако позднее, имея в своём распоряжении статистические данные, провайдер будет готов пойти на такие переговоры значительно проще и согласится поднять уровень компенсаций.
· Серые зоны в зонах ответственности. При любом аутсорсинге (и Облако тут не исключение) наиболее часто конфликты возникают относительно зон ответственности. Аутсорсер верит, что проблема была ещё до зоны его ответственности, а клиент убеждён, что ошибка была уже там, где зона ответственности провайдера наступила. Неясные границы создают множество споров и снижают общую надёжность инфраструктуры. Это крайне некомфортно для провайдера, поэтому он часто готов взять эти серые пограничные зоны под свой контроль. Например, любой облачный сервис зависит от интернет-канала, и клиент часто не может определить, была ли проблема с каналом или с самим сервисом. Т.к. это приводит к лишним обращениям в службу поддержки и делает клиента неудовлетворённым, провайдер может быть рад взять на себя контроль за мониторингом каналов связи.
Как потенциально бесконечный сервис Облако нуждается в регулярном повторении процедуры покупки. Это нормально, что на этапе подписания договора, обе стороны стараются выторговать лучшие условия «здесь и сейчас». Однако в процессе использования заказчик становится намного ближе к партнёру, чем к просто клиенту, и это правильное время, чтобы оптимизировать первоначальный контракт.
Контракт с провайдером – это не брачный контракт. Изменения допускаются.
Оставить свой комментарий:
Комментарии по материалу
Данный материал еще не комментировался.