Поделиться
Как продать ПО? Советы разработчику
Перед разработчиками программного обеспечения помимо основной задачи – собственно создать продукт – стоит еще одна, не менее, а иногда и гораздо более важная – вывести его на рынок. Нередко замечательные программы "хоронятся заживо", так и не заняв своего места на софтверном рынке. В результате разработчик остается у разбитого корыта, не зная, как решать проблемы, которые на этапе создания и тестов были не принципиальными.Второй путь - опять же аппаратные ключи. Платеж разбивается на несколько частей, причем так, чтобы общая сумма была несколько выше, чем та, которую клиент заплатил бы при единовременной покупке. Время работы продукта ограничивается определенным периодам, например, месяцем. По истечении месяца клиент должен заплатить очередную часть и получить от продавца обновление, которое позволит продукту работать в течение следующего периода.
Заметим, что описанная схема применима как к новым продуктам, так и к уже существующим. То есть создателям софтверной разработки не нужно заново "лезть" в код, чтобы встроить защиту и лицензионные ограничения.
Хотелось бы обратить внимание на еще одну проблему, возникающую у разработчиков программного обеспечения – организацию технической поддержки.
В большинстве случаев для технической поддержки и обновления специфического ПО пользуются услугами самого разработчика
Не секрет, что классическая схема реализации технической поддержки не гарантирует обращение к производителю именно легального пользователя. Во многих крупных компаниях служба техподдержки работает по следующему принципу: клиент звонит в службу и называет код регистрации программы. Однако этот код пользователь может передать кому угодно или выложить, допустим, в интернете. Учитывая это, многие разработчики оказывают техническую поддержку бесплатно, как следствие, упуская возможную дополнительную прибыль.
В организации платной технической поддержки опять же можно использовать опыт разработчиков, применяющих аппаратные ключи защиты своих программных продуктов.
Предположим, что производитель программного обеспечения продает техническую поддержку своего продукта по месяцам. Каждая копия приложения защищается с помощью ключа, таким образом, каждому пользователю соответствует уникальный ID-номер его ключа защиты. При обращении в службу технической поддержки пользователь предоставляет эти данные по телефону, e-mail или в онлайн-режиме web-интерфейса. Сотрудник службы технической поддержки с помощью аналогичного служебного приложения проверяет достоверность этих данных, а по ID-номеру ключа может легко идентифицировать клиента.
Главным преимуществом подобной схемы является быстрота и простота её реализации, а также исключение финансовых потерь от оказания услуг незарегистрированным пользователям.
Проблемы дилерские, решаемые
Выходя на рынок, разработчик программного обеспечения рано или поздно сталкивается с необходимостью организацией продаж продуктов через партнерскую (дилерскую) сеть. При этом возникает масса проблем, среди которых можно отметить следующие.
Незнание партнером рынка. Начиная работу на определенном сегменте рынка, дилер, как правило, плохо его знает. Это может привести к неправильным начальным инвестициям в программные продукты. Например, производитель программного обеспечения предлагает дилеру для распространения в регионе два программных продукта – light-версию и professional. Дилер, оценив рынок, принимает решение взять на реализацию десять продуктов light и два продукта pro. Через некоторое время у него распродаются два pro и ни одного light.
В результате дилер не получил ожидаемой прибыли. Он заморозил средства, которые могли пойти на раскрутку и продвижение продуктов, вложив их в плохо продаваемый продукт "В". Проиграли все. Разработчик ПО не получил ожидаемого дохода. Партнер не просто недополучил прибыли, он, вероятно, даже потерял деньги, так как они вложены в плохо продаваемый продукт (неизвестно, сможет ли дилер реализовать продукт и получить вложенные в него деньги).
Предварительную оценку, включающую анализ конкурентного окружения, платежеспособности, потенциальной востребованности продукта, требуемой маркетинговой активности и других факторов лучше проводить собственными силами (это не исключает использования специализированных агентств), не полагаясь на дилера, по крайней мере, на первичном этапе. Более того, некий "стартовый" комплект тоже лучше определить с самого начала, и по итогам его продаж, делать выводы относительно структуры рынка в данном конкретном регионе.
Партнеру необходимо держать склад программного обеспечения, чтобы оперативно реагировать на запросы клиентов, а это в ряде случаев может негативно сказаться на желании конкретного дилера работать с данным производителем ПО.
Возвращаясь к нашему примеру, дальновидный дилер должен был приобрести не два продукта pro, а, к примеру, десять. Убедительным аргументом с этой точки зрения опять же будет "стартовый" комплект, как идентификатор востребованности продукта, а следовательно необходимости обеспечить оптимальный запас продукта. Гибкая дисконтная политика на пробную закупку нового ПО или новых версий также позволит разработчику обеспечить лояльность дилера и мотивацию его к расширению ассортимента предлагаемого продукта.
Облегчить задачу дилера и снизить расходы на склад дилеру могут помочь те же аппаратные ключи защиты ПО. Вспомним схему с полным дистрибутивом продукта и возможностями ограничения по использованию его отдельных модулей. В этом случае дилеру не нужно закупать 10 версий pro и 10 – light, достаточно просто организовать схему добавления/пролонгации/удаления функционала, в том числе удалённо. Однако это – тема для отдельного рассмотрения.
Отсутствие оперативности также является проблемой, мешающей быстро развить бизнес. Партнер будет стараться минимизировать свои вложения в новое для него дело и брать на реализацию программные продукты по мере необходимости, тем самым значительно снижая оперативность обслуживания клиентов. Для многих проектов такая задержка в поставках может стать критической. Если клиент поймет, что поставки придется ждать какое-то время, он может обратить свое внимание на аналогичные продукты, предоставляемые конкурентами.
Чтобы этого не произошло, необходимо постоянно работать с дилерами, повышать их квалификацию и обращать пристальное внимание на то, как в каждом конкретном случае организованы продажи, техподдержка, система обновлений продукта в конкретной дилерской организации. Ни в коем случае не стоит отдавать эти аспекты ведения бизнеса полностью на откуп дилеру. Любой продукт имеет свою специфику продаж, однако дилеру по понятным причинам проще использовать некую единую универсальную схему для всех реализуемых им продуктов, что может негативно отразится на результатах продаж.
И, наконец - логистика. В условиях отсутствия склада и закупки товаров по мере их необходимости, затраты на логистику у партнера вырастают до огромных размеров. В результате либо снижается прибыль, получаемая при продаже товара, либо дилер повышает цену на продукт, что, разумеется, сказывается отрицательно на привлекательности продукта для клиентов.
От организации оптимальной логистической схемы, удобной и для дилеров и для разработчика в действительности зависит многое, начиная от удовлетворения потребностей клиента именно в тот момент, когда она возникла (как известно 80% продаж реализуется импульсивно и лишь около 15% потенциальных покупателей готовы вновь посетить ту торговую точку, где ранее они не нашли искомого) и заканчивая репутацией компании разработчика как в глазах "мультивендорного" дилера, так и с точки зрения конечного потребителя.
Выводы
Выпустив своё "детище" в большое рыночное плаванье, заботиться нужно не только о защите своей интеллектуальной собственности, которой в данном случае является созданная программа, но и о защите самого производителя софта от рисков упущенной прибыли.
Управление рисками в организации эффективных продаж на сегодня является, пожалуй, основной задачей разработчика, желающего не просто разработать инновационный продукт, но и добиться приемлемого уровня прибыльности данного направления.
Грамотно подойдя к дистрибуции программного обеспечения, продумав систему лицензирования и набор дополнительных сервисов и услуг, разработчик продукта может в несколько раз увеличить прибыль с продаж, безболезненно вывести свою софтверную разработку на рынок и более того – обеспечить ей лидерские позиции на этом рынке.
Александр Гурин, Ника Комарова
Короткая ссылка
