Pull to refresh

Comments 14

А по какой причине не удался референс-визит банкиров и нефтяников? Интересно было бы прочесть историю такой крупной встречи. Были ли случаи после не совсем удавшегося (или совсем неудавшегося) РВ по прошествии времени потенциальный клиент выбирал ваш продукт и заключал договор с вами?
Сыграли вилы на Шаге 3.
На двух предварительных встречах с потенциальным заказчиком (нефтяник) мы общались с бизнес- и ИТ-департаментами. Заинтересованность в нашем решении высказали оба отдела, была информация, что руководитель ИТ, кстати экспат, склонен с тяжелым зарубежным ECM-платформам, конкретнее к Документуму, но мы не предполагали, что это данное решение практически не поддается обсуждению.

Встреча длилась очень долго порядка 4 часов, больше половины рабочего дня, были задействованы много сотрудников, обсудили кучу вопросов и в итоге — пшик. Кстати руководитель ИТ был пассивен и в процессе не особо участвовал.
1. А не сталкивались с ситуацией, когда ни один из подходящих «старых клиентов» не соглашается на референс, а «новый» категорично его требует? Что делали в этой ситуации? Это актуально для молодых компаний, у которых всего два с половиной клиента и выбирать пока не из чего…

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

Один из заказчиков (крупная производственная компания) посетила презентации всех выбранных поставщиков ПО, порядка 5-7 компаний, среди которых была и наша. Следующим шагом они планировали провести референс-визиты к существующим клиентам.

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

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

По пункту 2:
Тут решение принимает заказчик (при условии что поставщик и старый клиент согласны на референс-визит). Все зависит от выделенных на внедрение системы средств.
1. Соглашение клиента на рефренс — предмет переговоров и торгов. У нас как у поставщиков всегда есть, что предложить старому доброму клиенту. Другой вопрос, что в начале карьеры всех желающих приходилось водить к одному-двум клиентам, за не имением других. Делать под потенциального клиента дополнительную проработку.

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

2. Посетить удаленного старого клиента предлагается потенциальному, при согласии, едем дружно, при отказе см. пункт №1
Всегда в своей работе стараюсь избегать референс-визитов, хотя клиенты преодически хотят посмотреть систему в действии. Стараюсь обходить их или высылкой материалов по проекту и отзыву клиента, или же звонком. Но иногда приходится идти на уступки.

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

С точки зрения «Старого клиента»:
— Интересно, что нового у производителя, какие нынче цены
— Перед визитом у поставщика легко можно выбить внеплановое халявное техобслуживание или тренинг(он сам заинтересован, чтобы всё работало хорошо)
— «Новый клиент» легко может дать ценный деловой контакт

С точки зрения «Нового клиента»:
— Производитель всегда вешает на уши лапшу и строит воздушные замки. Работающая система и довольный клиент — единственная правда
— «Старому клиенту» можно задать кучу провокационных вопросов и услышать альтернативной мнение
— Опять-таки — контакт

С производителем (интегратором) всё вообще чудесно. Балаболы и лентяи оказываются как на сковородке: и старых довольных клиентов нет, и у существующих показать нечего. А вот добросовестным работягам не грех продемонстрировать работающий продукт и тесную дружбу со старым клиентом.

Так что я — за.
Стратегия избежания референс-визитов аналогична таковой при избежании уличных конфликтов, но если ты живешь в неблагополучном районе и с работы приходится возвращаться поздно, надо быть готовым к драке :)

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

Очень желательно выйти на организацию с предлагаемой системой не со стороны внедренцев, а через связи руководителей своей компании или партнёров. К сожалению это не всегда возможно. Ценность встречи, проведённой (а тем более — отрепетированной как предлагается в статье) внедренцем значительно меньше «случайной».

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

За статью спасибо. Не забываем читать наоборот.
Ну, просто тот факт, что старый клиент дружит с поставщиком — уже неплохо (может и с вами будет дружить). А кроме того, даже если перед вами разыгрывается спектакль «для ревизора» — кто же мешает посмотреть на реальное железо, программу, на людей, которые это используют, позадавать вопросы, смоделировать проблемку — и попросить показать её решение. Вы же платите (ну или будете) — так заказывайте музыку.
Каким образом вы увидите и почувствуете реальную картину проекта? Переговоры обычно проходят в конференц-зале, есть ноут в сети, на котором запущена система, многие параметры описываются на словах. Я могу сказать что в системе 100 тыс. документов, а могу сказать что 10 миллионов, в системе безопасности покажу 6 тыс учетных записей и скажу что в пиковые часы одновременных пользователей 4 тыс, а на самом деле — десять человек. Можно увидеть явные баги, если они есть, но если встреча нормально подготовлена, сам старый клиент скажет куда не нажимать, чтобы все не повисло.

На «случайных» встречах сильно сомневаюсь, что вы чего-либо кроме случайностей увидите, но как вариант рассматривать можно.

Спасибо за спасибо. По прочтении наоборот имело бы смысл опытному «потенциальному клиенту» написать дополнительную статью в продолжение о том, на что обращать внимание и как раскручивать на правду поставщика и его «обученного» клиента.
Несколько странно что вы продолжаете описывать искусные приёмы обмана своих потенциальных заказчиков.

В моём случае не было ни конференц-зала, ни заряженного «старого клиента» (иногда, к сожалению попадались), ни менеджера, ведущего переговоры. Зато со мной были опытные представители целевых для системы подразделений которые общались со своим коллегами в рабочих кабинетах. Мне повезло — наши сотрудники отлично знали свой work flow и тонкие места автоматизации знакомых им процессов.

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

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

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

Отдельную статью можно написать, чтобы не забыть практические приёмы (не так часто приходится выбирать серьёзные системы серьёзным заказчикам), но и ваша является отличным подспорьем для думающих специалистов.
тематика статьи не очень близка мне, но понравилось как все изложено. стуктура статьи, шаги, блок-схема, ссылки в конце. хороший пример.
Sign up to leave a comment.