10 мая 2011г. Автор: Тарус Балог
Изображение: opensource.com
В идеальном мире процесс продаж открытого ПО был бы проще простого - ответить на телефонный звонок и принять заказ. К сожалению, реальность далека от идеала, и процесс продажи открытой программы потребует решения нескольких проблем.
Основная проблема - большинство компаний привыкли вести дела определенным образом, и хотя этот стандарт неплохо работает с коммерческим ПО, традиционная модель никуда не годится для открытого ПО. (Для справки: речь идет о настоящих открытых программах, где стоимость лицензии равна нулю.)
Демонстрационная версия (proof-of-concept) - не лучший выбор
Например, если компания хочет купить программное решение для организации работы предприятия, поставщик коммерческого ПО согласится предоставить демонстрационную версию, т.н. proof-of-concept. То есть: поставщик ПО отправит инженера - за свой счет - который установит демонстрационную версию программы клиенту и расскажет ему о возможностях программы, заострив внимание на том, как она подходит для конкретной ситуации покупателя.
Некоторое время программа работает, чтобы потенциальный покупатель мог оценить ее преимущества. Затем, когда время работы демо-версии истекает, программа перестает работать - требуется покупка полноценной лицензии. Так как цена лицензии весьма высока, поставщику выгодно производить поставку демо-версии за свой счет - даже одна проданная программа в итоге окупит множество безрезультатных установок.
Но с открытым ПО этот метод не работает. Ваша компания может установить программу, провести конфигурацию под нужды клиента и показать ему, как ей пользоваться, но ваши затраты уже не возместить с помощью лицензионного сбора. В общем, хотя демо-версии хорошо подходят для демонстрации продукта потенциальному клиенту, в случае с открытым ПО окупить их будет нечем.
Опасайтесь компаний, которые предложат вам “установить и настроить программу, чтобы мы ее оценили - а потом мы сразу заключим контракт на обслуживание”.
Особенно в том случае, если они ранее с вами не связывались, но хотят купить самый дорогой продукт из предлагаемых вами. Серьезность намерений в таком случае вызывает сомнения. Скорее всего, они полагают, что если поманят будущим контрактом, вы окажете им бесплатные услуги. Такие клиенты вам не нужны.
Нужны те, кто понимает -ваше время и опыт стоят денег. Хотя почти все компании в сфере открытого ПО производят программы, зарабатывают они обслуживанием программ, так что лучше всего будет сосредоточиться на доходе от услуг. И хотя это может показаться неочевидным, следует брать деньги за предварительную продажу.
Как я уже замечал выше, компании привыкли вести дела определенным образом, и многим может не понравиться плата за возможность оценить решение. Переломить такое мышление трудно. Иногда я объясняю это клиенту так - вы платите доктору, автомеханику и водопроводчику за их знания. Они предоставляют услугу, а не товар. Открытое ПО - то же самое. Сам товар бесплатный; компании же существуют для того, чтобы программа работала наилучшим образом у конкретного клиента.
Когда вы только начинаете, есть искушение проводить пробные установки бесплатно. Я советую вам - попытайтесь удержаться от этого. Я не против потратить час на базовую демонстрацию по Интернет, но за что-то большее все же следует заплатить. Мы в OpenNMS продаем время, как наше (что само собой разумеется), так и время наших клиентов. Наш опыт помогает снизить затраты времени на установку и внедрение (а значит, и общие затраты). Наши клиенты знают об этом и уважают наши знания.
Заявка на коммерческое предложение - в большинстве случаев трата времени
Мы подходим к самой худшей черной дыре, где безвозвратно теряется время компании-разработчика СПО - это заявки на коммерческие предложения (Request for proposal, RFP).
Если вы работали над автоматизированными управленческими системами, вы видели такие заявки. Это огромные документы, описывающие гигантские программные проекты с очень жесткими требованиями к поставщику - которые почти никогда не подходят для модели оказания услуг, распространенной в нашей отрасли. Однажды мне предложили поучаствовать в заявке на предложение для крупной программной системы для колледжа в Калифорнии. Документация сообщала, что все услуги будет оказывать другая компания, хотя я мог подать свою заявку.
Худшие заявки на коммерческое предложение я называю “Аве Мария” - так называют крайне неудачный пас в американском футболе (‘Hail Mary‘). Это такие заявки, где какая-то компания хочет участвовать в проекте, но ей не хватает какого-то компонента, и они просят вас выступить субподрядчиком. Вот пример (из реального электронного письма):
“У меня тендер в Турции, я хотел бы подать заявку. Тендер в отрасли телекоммуникаций, мы собираемся предложить [решение №1] и [решение №2] оператору связи. Клиенту нужна система управления устройствами. Хотя есть примитивный функционал для управления ими, мы предполагаем, что работу придется выполнять с нуля.
Если вы хотели бы подать заявку на поставку решения для этого тендера, я передам вам часть, где требуется разработать систему управления. Заявка требует NMS; системы контроля за ошибками, системы контроля производительности и инвентаризации”.
Очень “мутный” заказ. В одном абзаце поставщик предлагает моей компании заняться неоплачиваемой работой в течение как минимум недели. И даже в лучшем случае мы будем лишь субподрядчиком у третьего лица, которое не имеет понятия ни о нашем продукте, ни о нашем бизнесе.
Даже те заявки, которые вы подаете напрямую заказчику, едва ли стоят ваших сил. В прошлом году у нас была потенциальная заявка, которая казалась нам стоящей тратой времени. Я даже нанял эксперта, чтобы составить ответную документацию. Потратив несколько тысяч долларов и проработав несколько недель, мы проиграли тендер.
Я не говорю, что все заявки - плохие, и не стоит вообще на них отвечать, но предупреждаю, что для большинства компаний-разработчиков открытого ПО такие заявки не оправданы в финансовом отношении. Охотиться за крупной дичью - может, и хорошая идея для компаний, получающих большой доход от стоимости лицензии. Но для открытого ПО такая тактика редко оправдывает себя.
Как и в случае с предварительными продажами, так и в случае с заявками на проект я бы предложил клиенту приобрести план оказания услуг, чтобы воспользоваться открытым ПО в качестве решения. Даже если на это уйдет неделя-другая, затраты ничтожны по сравнению с коммерческими решениями, которые могут обойтись в сотни тысяч, а то и миллионы долларов.
Саймон Фиппс недавно написал статью о том, что компаниям следует быть готовыми заплатить за открытое ПО столько же, сколько они платят за такое же проприетарное решение, хотя у открытого ПО нет затрат на лицензию. Я не спорю с этим, но важно другое - компании, продающие открытое ПО, должны пересмотреть свои взгляды на весь процесс продажи.
Свобода, по умолчанию доступная любому пользователю открытого ПО, означает, что созданные на его основе решения будут дешевле, как при внедрении, так и при дальнейшем владении, и не только из-за того, что лицензия бесплатна, но и потому, что решение более качественное. Я указываю потенциальным клиентам, которые не уверены, что хотят платить за демонстрацию: “Возможно, вы и не захотите воспользоваться открытым ПО, но будьте уверены в том, что ваши конкуренты попробуют, а сэкономленные средства направят на улучшение обслуживания.
И когда конкуренты будут оказывать услуги лучше вас, как вы удержите своих клиентов?”
