Акция

Миграция с других систем

Скидка на систему «ДЕЛО» при миграции с других решений.

Получите демоверсию и консультацию

+7(495) 221-24-31

Вернуться к списку

Как продать ПО? Советы разработчику.

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

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

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

Претензии клиентов, связанные с плохой работой дополнительных сервисов (а зачастую именно из-за них был сделан выбор в пользу этого конкретного продукта), часто распространяются на весь продукт (в общем неплохой). Кроме того, софт получается неудобным в использовании. Но самое главное ¬– цена такого продукта становится непомерно высокой. Понятно, что это оказывает негативное влияние на принятие решения о приобретении. Согласитесь, не каждый клиент готов выложить кровно заработанное за софт, половиной функций которого он будет пользоваться чисто теоретически. Следовательно, разработчики недополучают ожидаемой прибыли. А на высококонкурентных рынках такое увеличение цены может оказаться и вовсе фатальным.

Трудности позиционирования

Другая проблема, которая возникает перед разработчиками, – позиционирование продукта. Повышая стоимость программы за счет ее универсальности, разработчик невольно сужает свой рынок сбыта, делая продукт недоступным для небольших клиентов и рассчитывая только на крупную корпоративную "рыбу".

На деле решение этой проблемы лежит на поверхности. Достаточно поделить программу на модули и сформировать нескольких версий с ограниченной и полной функциональностью.

При разработке ПО вендор должен разделить весь функционал на три независимые части: необходимый – решающий основные проблемы, достаточный - решающий все задачи, а также набор сервисов, создающих дополнительные возможности и комфорт при работе с программой.

Из необходимого функционала формируется так называемая "light" версия. Эта версия должна решать все насущные проблемы клиента, но при этом вызывать непреодолимое желание расширить возможности приложения. Говоря простым языком, в облегченной версии чего-то должно не хватать, она должна быть немного неудобной. Причем возможности полной, "профессиональной" версии ни в коем случае нельзя скрывать. Клиент должен видеть недоступные (пока) ему возможности. Это могут быть неработающие в light-версии кнопки, иконки и т.д.

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

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

А зачем нам кузнец?

Сервисы, которые делают работу с программным продуктом комфортнее, всегда следует выносить за рамки основной версии и продавать отдельно по мере необходимости. Это простой рыночный принцип: "за удобство нужно платить".

Вопрос, которому действительно стоит уделить пристальное внимание - разделение собственно защиты и лицензирования. Установка лицензионных разграничений должна быть компетенцией не программиста, а менеджера. А вот задачи по построению защиты должны оставаться на совести разработчика. Таким образом, при постановке задачи на разработку ПО менеджеры определяют, какие функции войдут в light-версию, какие – в полную, и какие сервисы будут предоставлены дополнительно. Далее разработчики встраивают защиту и выпускают полный дистрибутив, содержащий всю функциональность. В случае использования для защиты аппаратных ключей, ограничения записываются в память ключа. При использовании софтверной защиты, менее надёжной, но имеющей право на существование, определяемое низкой стоимостью самого программного продукта, это реализуется в коде.

В первом случае клиенту поставляется полный дистрибутив вместе c аппаратным ключом. Однако покупателю будут доступны только те функции, за которые он заплатил, и разрешения на которые присутствуют в памяти ключа. При необходимости расширения функционала клиент отправляет запрос на обновление. После поступления оплаты менеджер продавца генерирует обновление памяти для ключа клиента и отправляет его по e-mail. После установки обновления у покупателя появляется расширенный функционал.

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

Как продать и не пострадать

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

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

А между тем такая проблема легко решается организацией аренды или лизинга продукта. Для этого необходимо реализовать ограничение по времени использования продукта. С этим методом многие встречались на примере антивирусов. Как известно, антивирусные базы необходимо обновлять, соответственно антивирусные вендоры встраивают ограничение на использование продукта на какой-либо срок, в течение которого ваш антивирус исправно обновляется. По истечении этого срока вы обязаны либо пролонгировать действие лицензии, либо отказаться от использования продукта, либо продолжать использование, но уже на свой страх и риск. Понятно, что и в этом случае вопрос безопасности и денежных рисков стоит во главе угла.

Второй путь - опять же аппаратные ключи. Платеж разбивается на несколько частей, причем так, чтобы общая сумма была несколько выше, чем та, которую клиент заплатил бы при единовременной покупке. Время работы продукта ограничивается определенным периодам, например, месяцем. По истечении месяца клиент должен заплатить очередную часть и получить от продавца обновление, которое позволит продукту работать в течение следующего периода.

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

В большинстве случаев для технической поддержки и обновления специфического ПО пользуются услугами самого разработчика

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

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

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

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

Проблемы дилерские, решаемые

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

Незнание партнером рынка. Начиная работу на определенном сегменте рынка, дилер, как правило, плохо его знает. Это может привести к неправильным начальным инвестициям в программные продукты. Например, производитель программного обеспечения предлагает дилеру для распространения в регионе два программных продукта – light-версию и professional. Дилер, оценив рынок, принимает решение взять на реализацию десять продуктов light и два продукта pro. Через некоторое время у него распродаются два pro и ни одного light.

В результате дилер не получил ожидаемой прибыли. Он заморозил средства, которые могли пойти на раскрутку и продвижение продуктов, вложив их в плохо продаваемый продукт "В". Проиграли все. Разработчик ПО не получил ожидаемого дохода. Партнер не просто недополучил прибыли, он, вероятно, даже потерял деньги, так как они вложены в плохо продаваемый продукт (неизвестно, сможет ли дилер реализовать продукт и получить вложенные в него деньги).

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

Партнеру необходимо держать склад программного обеспечения, чтобы оперативно реагировать на запросы клиентов, а это в ряде случаев может негативно сказаться на желании конкретного дилера работать с данным производителем ПО.

Возвращаясь к нашему примеру, дальновидный дилер должен был приобрести не два продукта pro, а, к примеру, десять. Убедительным аргументом с этой точки зрения опять же будет "стартовый" комплект, как идентификатор востребованности продукта, а следовательно необходимости обеспечить оптимальный запас продукта. Гибкая дисконтная политика на пробную закупку нового ПО или новых версий также позволит разработчику обеспечить лояльность дилера и мотивацию его к расширению ассортимента предлагаемого продукта.

Облегчить задачу дилера и снизить расходы на склад дилеру могут помочь те же аппаратные ключи защиты ПО. Вспомним схему с полным дистрибутивом продукта и возможностями ограничения по использованию его отдельных модулей. В этом случае дилеру не нужно закупать 10 версий pro и 10 – light, достаточно просто организовать схему добавления/пролонгации/удаления функционала, в том числе удалённо. Однако это – тема для отдельного рассмотрения.

Отсутствие оперативности также является проблемой, мешающей быстро развить бизнес. Партнер будет стараться минимизировать свои вложения в новое для него дело и брать на реализацию программные продукты по мере необходимости, тем самым значительно снижая оперативность обслуживания клиентов. Для многих проектов такая задержка в поставках может стать критической. Если клиент поймет, что поставки придется ждать какое-то время, он может обратить свое внимание на аналогичные продукты, предоставляемые конкурентами.

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

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

От организации оптимальной логистической схемы, удобной и для дилеров и для разработчика в действительности зависит многое, начиная от удовлетворения потребностей клиента именно в тот момент, когда она возникла (как известно 80% продаж реализуется импульсивно и лишь около 15% потенциальных покупателей готовы вновь посетить ту торговую точку, где ранее они не нашли искомого) и заканчивая репутацией компании разработчика как в глазах "мультивендорного" дилера, так и с точки зрения конечного потребителя.

Выводы

Выпустив своё "детище" в большое рыночное плаванье, заботиться нужно не только о защите своей интеллектуальной собственности, которой в данном случае является созданная программа, но и о защите самого производителя софта от рисков упущенной прибыли.

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

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

Источник: http://www.pda.cnews.ru/reviews/index.shtml?2007/06/01/253051_1


Возврат к списку


Ольга Савко

Начальник группы телемаркетинга

Получите качественную бесплатную консультацию

Акция

Переход на отечественную АИС МФЦ

Скидка на право использования АИС МФЦ «ДЕЛО» при миграции с других решений по автоматизации МФЦ

Акция

«Амнистия» по техподдержке

Акция для клиентов, у которых есть просроченная техподдержка до 01.01.2015

Календарь мероприятий

15ноября

ЭОС - участник форума «Искусственный интеллект, большие данные, отечественный софт: национальная стратегия»

Узнать больше

26октября

Важнейшее IT-событие октября - конференция «Осенний документооборот»

Узнать больше

09октября

ЭОС - участник Всероссийского форума «ПРОФ ИТ»

Узнать больше

Наши клиенты

7 000 компаний

Наши партнеры

250

во всех городах России
и странах СНГ