Что это такое? Зачем мы так поступаем? Почему нельзя было сделать «как все»? Этой публикацией хотелось бы ответить на вопросы и, если будет интересно, предложить дальнейшее общение.

Итак, почему абонементы?

Стадия 1. Как было?

Как это обычно бывает, свою позицию легче объяснить, если проследить историю. В данном случае давайте посмотрим, как трансформировалось понятие цены на программное обеспечение в области САПР.

Исторически сложилось так, что САПР — достаточно дорогое удовольствие: это инструмент производства, а инструменты стоят дорого. Несмотря на широкий разброс цен (от 200 до 20 000 $ и выше), основная масса САПР находится в диапазоне от 3000 до 6000 $. Это цена одного рабочего места — если в проектной организации работает 50 человек, то смело умножайте на 50. Конечно, даже для организаций, которые профессионально занимаются проектированием, это высокая цена. А уж для прочих производств (и тем более для простых пользователей) такая цена лицензионной программы не окупается. Неужели закрываться или чертить на кульмане с помощью карандаша и ластика, откатываясь в прошлое и окончательно теряя конкурентоспособность? Неудивительно, что пиратство процветает…

Классический способ (рис. 1) распространения программного обеспечения базируется на принципе «Купил бесконечную лицензию, а следующая версия — по цене обновления». Это похоже на распространение книги (то есть интеллектуального товара): разработчик пишет версию (книгу), оформляет ее в некий товар (коробка, документация, диск, ключ защиты), выпускает товар на рынок и продает на протяжении какого-то периода. Если в текущей редакции книги (ой, программы) пользователи находят ошибки, то выпускаются исправления. Если продажи были успешны, набралось достаточное количество замечаний к первой версии, — выпускается новая версия и круг повторяется. На новом круге исключение только для текущих лицензионных пользователей — они могут сделать льготное обновление со старой версии, которое обычно составляет 20−30% от ранее выплаченной цены. Все просто, правда?

Рис. 1. Классическая схема продаж: „Купил лицензию, а затем купиобновления“
Рис. 1. Классическая схема продаж: „Купил лицензию, а затем купиобновления“

По опыту продаж можно отследить, что даже в нашей стране с высоким уровнем пиратства лицензионные пользователи делают обновление примерно раз в 1−3 года. Но какая-то часть пользователей, купивших лицензию, уходит потом на конкурентные решения (редко) либо на пиратские версии (чаще) — последнее особенно серьезно усложняет жизнь разработчикам и раздражает их…

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

Стадия 2. Как сейчас?

С развитием рынка постепенно складывается новая схема продаж, которую можно сформулировать так: «Купил бесконечную лицензию, а затем купи поддержку и регулярные обновления». Идея заключается в том, что разовые обновления перемещаются в русло регулярных выплат (рис. 2). Поясню.

Рис. 2. Обновленная схема продаж: „Купил лицензию, а затем купи поддержку“
Рис. 2. Обновленная схема продаж: „Купил лицензию, а затем купи поддержку“

Для нового пользователя ничего не меняется — он покупает лицензию за ту же цену, что и ранее. Но вот текущий пользователь может (или должен — в зависимости от политики разработчика) «размазать» по времени платеж за обновление и «поставить» свое программное обеспечение на поддержку, регулярно выплачивая разработчику некий фиксированный взнос (обычно 10% от цены на новые лицензии). Фактически это некий кредит за будущие обновления и вопрос доверия разработчику, правда?

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

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

Можно заметить, что новый подход перемещает программное обеспечение в разряд услуги: сначала пользователь покупает товар (упакованную последнюю версию программы), а потом оформляет услуги на техническую поддержку. Но тут тоже есть тонкости…

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

Во-вторых, купив товар с бессрочной лицензией, пользователь обманывается — программа не будет работать бесконечно. Сомневаетесь? Ну тогда попробуйте запустить под новыми ОС программу, вышедшую 10 лет назад. Еще вариант: запросите техническую поддержку на САПР, работающую под DOS или купленную 5 лет назад. В лучшем случае техническая поддержка с вами мило побеседует. Да и что они могут сделать? Поднять старый код и начать его исправлять? Скорее всего, вам дадут дружеский совет: обновите программное обеспечение. За дополнительные деньги. То есть лицензией вы обладаете, но пользоваться ею не можете. Идти к пиратам за новыми версиями?

Стадия 3. Абонементы

И тут мы приходим к следующей мысли — а почему бы программное обеспечение окончательно не оформить как услугу: «Купи абонемент, который состоит из коммерческой лицензии, поддержки и обновлений» (рис. 3). Ведь мы пользуемся услугами тренажерных залов, арендуем помещения, станки, машины, оплачиваем разговоры по мобильному телефону, посещаем кинотеатры — почему бы не вписать в эту схему и программное обеспечение?

Рис. 3. Основная схема продаж ЗАО „Нанософт“: „Купи абонемент“
Рис. 3. Основная схема продаж ЗАО „Нанософт“: „Купи абонемент“

Итак, неужели аренда программного обеспечения? Смотрите — достаточно привлекательно:

  1. Абонементы делают лицензионное программное обеспечение более доступным. Если на стадии 2 мы «размазали» цену обновления, то при абонементах «размазывается» сама цена программного обеспечения (сокращаясь, например, в 3−4 раза — усредненное время работы с одной версией программы) — смотрите рис. 3: первоначальный барьер снижен и САПР становится доступна даже частному проектировщику. Мы верим, что при прочих равных условиях пользователь выберет лицензионный софт, а не пиратский. Абонементы — хороший способ проверить, так ли это ☺.
  2. Абонементы позволяют переместить издержки на программное обеспечение из разряда переменных в разряд постоянных. Это хорошо как разработчикам (регулярное поступление финансов ☺), так и пользователям — постоянные расходы легче контролировать и планировать, проводить по бухгалтерской отчетности.
  3. Абонементами легче управлять. Сократилось число проектировщиков? Сокращаем число купленных абонементов. Переконфигурировались рабочие места? От части абонементов отказываемся, другие закупаем. Гибко.
  4. Абонементы позволяют реагировать на требования клиентов. Клиенту удобно платить раз в год? Пожалуйста, годовой абонемент. Раз в два года? Двухгодовой абонемент. У клиента особые запросы к программному обеспечению и его обслуживанию? Можно разработать специализированные абонементы, которые будут включать в себя расширенную техническую поддержку, обучение сотрудников, настройку программного обеспечения, разработку новых модулей и т.д.
  5. Абонементы защищают заказчиков от необдуманных затрат. Если программное обеспечение не устраивает, не развивается или его развитие ушло в направлении, не оправдывающем ожидания клиентов, то на следующий год клиенты абонемент просто не продлевают, сигнализируя разработчику: «в королевстве датском» чтото не то.
  6. Абонементы позволяют программе развиваться быстрее. Разработчики заинтересованы в регулярном обновлении программ и развитии их функционала. Это, кстати, большая ответственность для разработчиков — если развивать нечего, то приходится обновлять интерфейс ☺.
  7. Абонементы — это единственный путь при интенсивном развитии программы. «Классическая» схема продаж хороша, если программа выпускается раз в 2−3 года. Но если новые версии выходят раз в полгода, то для пользователя эта схема будет слишком дорогой, лучше немного притормозить с покупкой и подождать, когда программа наберет функционал. Абонементы позволяют не откладывать на потом то, что можно приобрести сегодня ☺.

Не думаю, что перечислил все преимущества абонементов…

Итак, абонементы — это некий компромисс, и у пользователей появляется возможность приобрести программный продукт по цене, которая устраивает разработчиков. Теоретически идея пиратства изживает себя, нет? ☺

Но на практике при реализации абонементов возникает тонкость — абонементы должны быть ограничены по времени, иначе их смысл теряется. То есть программное обеспечение через какоето время должно прекратить работу. «Как? Вы забираете у нас лицензию на программу? Она перестает работать? А если нам через год понадобится подправить чертежи? Вы подсаживаете нас на иглу?», — говорят пользователи. Тут несколько решений: либо сохранить возможность работы с чертежами после окончания срока действия абонементов (например, с помощью бесплатной платформы nanoCAD), либо все-таки оставить альтернативную схему продаж (в конце концов, посмотрев фильм в кинотеатре, зритель может купить DVD-диск для повторного просмотра дома).

Заключение

Возникает вопрос: а какая схема лучше? Мы думаем, что абонементы — схема более разумная и удобная. В IT она реализуется при продажах интернет-сервисов и системного программного обеспечения (антивирусы, фаерволлы и т.д.). Именно ее мы реализовали в первую очередь, несмотря на то что для российского рынка САПР это в новинку, а многие пользователи пока ее не воспринимают и требуют коробочной поставки. А что думаете вы?

P. S. Кстати, классическая коробочная поставка для вертикальных решений нами все-таки реализуется: nanoCAD СПДС 2.0, nanoCAD Механика 2.0 уже можно купить как коробки за 25 тыс. руб. (против 7 тыс. руб. за годовой абонемент). Все последующие платные программные продукты будут продаваться и по абонементной, и по коробочной схеме.

P. P. S. Интересно? Продолжать? Если да, то какие темы интересны в дальнейшем?

Денис Ожигин
ЗАО «Нанософт»
E-mail: