Никак не решает, потому что нет таких чудиков с такими чудными запросами.
Лично я бы действовал...
Сегодня у бизнеса есть доступ к передовым технологиям, финансированию и квалифицированным кадрам, однако многие компании по-прежнему придерживаются устаревших моделей работы. Что на самом деле останавливает организации на пути к инновациям? Как заказчики принимают решение о ценности и необходимости технологических изменений?
Это законно?
Детальное сравнение с конкурентами (иногда - даже не очень детальное) может привести к судебному разбирательству. Невозможно доказать, что сравнение сделано корректно - или придётся рассказать в суде, как были получены чужие коммерческие и технические секреты, защищенные самыми разными правами.
Заказчик может устроить кастинг и предложить поставщикам дать свои продукты для тестирования в песочнице на обговоренный срок. После этого ему можно делать какие угодно выводы, правильные или неправильные, не важно.
Но исполнитель себе такое позволить не может.
Да, это законно.
Любой производитель стремится продать свой продукт, поэтому можно запросить материалы о нем. И не просто запросить - попросить заполнить форму сравнения.
В рамках одного проекта приходилось выбирать системы автоматизации, для чего были запущены стандартные опросники - всего более 1000 вопросов. Все желавшие участвовать вендоры (SAP и др. того же уровня) старательно их заполнили. После этого на основе скоринговой оценки по блокам вопросов был выбран победитель, который и получил право предоставить продукт.
Конечно, нужно смотреть на цену заказа, но в любом случае можно выделить 10-20 сутевых вопросов, которые позволят разделить продукты. В самом простом случае заполнить опроснить можно и самому в рамках телефонного разговора с отделом продаж.
Возможно имеется в виду сравнение с характеристками конкурентов, указанными в их открытой документации.
Но тут я вижу другую проблему, мы можем считать, что они в открытой (рекламной) документации дали харктеристики лучшие, чем они могут реально обеспечить, поэтому мы не хотим с ними сравнивать, а данных о реальных характеристик у нас законно нет.
Тут есть еще один момент, конкуренты могут давать характеристики, по которым у них превосходство и умалчивать характеристики, которые у них слабые, но опять же, зная это, мы не можем официально это заявить.
Кем были запушены опросники? Покупателем?
Заказчик, даже будущий, естественно, может что-то спрашивать у производителя. А независимые лаборатории могут проводить тесты и делать сравнения с длинным списком оговорок.
Но один производитель, насколько я понимаю, не может сравнивать себя с другими, говоря о своих преимуществах и чужих недостатках и не получив на это разрешение.
Например. Всё перечисленное и еще много вариантов.
Вы неправильно поняли или исказили то, что содержится в нашей документации. Вы не понимаете, как работают наши непревзойдённые технологии и придуманные нами протоколы. Вы не учились на наших курсах и не получали сертификаты высокого уровня, чтобы правильно работать с нашими продуктами. Вы сравнивали не с той версией. Далее везде.
Для юристов такие публично ошибающиеся - лёгкая добыча.
Не вижу ничего противозаконного. Речь не идет о раскрытии какихто технологичских ноу-хау. Все из открытых источников. Сравнение идет по укрупненным функцям, например, существет ли настройка сценарев: да/нет.и выставляется вес той, или иной функции.
При разговоре с конкурентами даже ссылались на это исследование.
Ну последнее время стараются использовать стандартные протоколы, хотя свои тоже есть.
Старые частные никуда не делись, и крупные вендоры, начиная с лидеров, заинтересованы в их использовании. Это дополнительно привязывает их клиентсую базу.
Для Систем автоматики промышленного оборудования важно обеспечивает ли протокол передачи данных гарантированное время доставки тех или иных параметров и какое это время.
Бывает так, что некоторые производители используют протоколы, которые пропускают большой объем данных, но нет гарантированного время доставки, а для определенных параметров (их может быть немного) очень важно иметь такую возможность для настройки.
Там бывает надо провести расчет времени реагирования от параметра на датчик до срабатывания исполнительного механизма.
Охотно верю. Можно начать даже с обычных банкоматов, анализа качества каналов связи и способов подключения с гарантированной доставкой. Даже не говорю о телеметрии. Сколько на свете накопилось хороших и разных протоколов за все годы и на все случаи.
Сюжетов много. Посмотрите на собственные протоколы Cisco.
Мы тоже используем все технологии стандартные и популярные. Заказчики сейчас не хотят привязываться к одному исполнителю, а даже если и хотят работать с кем-то одним - хотят иметь потенциальную возможность альтернативы
Нами, от имени консалтинга, с указанием на представление интересов заказчика, но без его раскрытия. Покупатель просто финансировал отдельный проект по выбору IT-системы.
Такое сравнение на стороне вендора и не требовалось: нужно было просто заполнить матрицы с вопросами: дать ответ (часто - выбрать из ряда предложенных вариантов) и подтвердить ссылкой на документацию, где это могло быть найдено. Никакие чужие недостатки раскрывать не требовалось.
После этого все матрицы объединялись в рамках одного файла и сравнивались по блокам с выставлением баллов. Поскольку задача была разовой, все удалось выполнить средствами Excel. На выходе получился набор паутинообразных диаграмм (radar charts) с указанием на пересечение областей покрытия требовавшегося заказчику функционала. Это позволило наглядно сравнить ширину и глубину фактических возможностей, а также потенциала каждой единицы софта.
Именно так и у нас происходило. Я даже удивлен сомнениям в законности такого варианта. В сети тысячи сайтов, где сравниваются по функционалу тысячи приложений. Наш партнер предложил именно такой вариант.
Radar Charts - это замечательно. Рад, что их хватило.
Всё зависит от сложности конфигурации и новизны задачи. Далеко не всегда даже положительнные ответы вендора отражают действительность. Очень многое нужно проверять в ходе проекта, особенности при интеграции и на стыках.
Оценить функционал, степень соответствия требованиям и - тем более - трудоёмкость реализации без тестирования практически невозможно. Условно базовые вещи делают многие, дальше начинаются неожиданности. Дьявол в деталях. В этом проблема больших IT проектов.
Согласен. Когда делается большой проект могут появиться 'подводные камни' в процессах заказчика и договоренности, которые были на старте могут не сработать. Тут и появляются проблемы: не хватает бюджета, не работает софт так, как задумывалось, процессы внутренние поменять невозможно и т.п. Поэтому мы дошли до того, что не пишем полное подробное ТЗ в деталях, а прописываем концепцию и суть с основными деталями и если это все заработает нормально у заказчика - заключаем договор на техподдержку и уже в ходе техобслуживания дорабатываем детали. Такой метод на практике наиболее жизнеспособный в больших проектах. Но это на нашем опыте. У других может быть по другому и далеко не все заказчики соглашаются работать нашими методами