Основное

  1. Тот факт, что продукт используется в части успешных компаний, не означает, что он лучше, чем другой. Бренд вендора защищает принимающих решение руководителей на высоком уровне, поэтому совершить ошибку с известным коммерческим продуктом персонально безопасней, чем с бюджетным и менее известным.
  2. Стоимость лицензии никак не коррелирует с полезностью продукта в ваших конкретных условиях. Для этого, по сути, нет причин. Экономически, вложение в маркетинг для производителя эффективнее, чем вложение в специализацию — поэтому, в современных продуктах, готовый функционал делается поверхностно. Что действительно важно при выборе, так это управление циклом разработки и обратная совместимость при обновлениях.
  3. При работе с внешним исполнителем не рассчитывайте на его экспертизу в вашем бизнесе. Лучший внешний исполнитель в ИТ, в первую очередь, узкий специалист в технологии, и лишь во вторую, отраслевой эксперт. Много проектов и известные заказчики означают, что у исполнителя хороший процесс продаж, но не означают, что аналитик, выделенный на ваш проект, съел собаку в вашей отрасли.
  4. Нельзя делать слишком большое ТЗ. В случае большого ТЗ, в конце у Вас будет огромная работа по приёмке результатов, формированию замечаний, и всё это закончится тем, что половина задуманного функционала не будет использоваться. В случае маленького ТЗ, в конце у Вас будет минимально-необходимый рабочий функционал и понимание реальных возможностей исполнителя.

О работе ИТ маркетинга

Я много раз видел доклады об использовании одного CRM-продукта: люди из крупных компаний некоторой отрасли говорили как они выбрали его, делясь ожиданиями и первыми (!) результатами; другие люди из крупных компаний других отраслей сообщали о простоте внедрения и полном охвате цикла работы с клиентом. Вендор соединял всё это в единое мета-сообщение.

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

О желании проскочить этап

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

Так вот, интегратор всегда срежет объёмы внедрения, если окончательная цена определена. Заставить что-либо выполнить, если это не было детально прописано, невозможно. При наличии рамочного ТЗ, они будут играть деталями.

Последствия

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

Обычно, проект тихо хоронят год-два спустя. Неплохая иллюстрация тут.