Абонементы на ПО: быть или не быть?

Денис Ожигин

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

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

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

Заключение

Полтора года назад была образована компания «Нанософт», которая объявила своей целью разработку первой бесплатной отечественной САПР-платформы nanoCAD. В ноябре этого года платформа наконец-то вышла как отдельный продукт — сразу в версии 2.0 (предыдущая версия лежала в основе программных решений nanoCAD СПДС 1.0 и nanoCAD Механика 1.0). В свою очередь, вертикальные приложения на базе платформы nanoCAD распространяются по несколько непривычной (особенно для консервативного мира САПР) схеме продаж — по абонементам.
Что это такое? Зачем мы так поступаем? Почему нельзя было сделать, «как все»? В настоящей публикации хотелось бы ответить на эти вопросы и, если будет интересно, предложить дальнейшее общение.
Итак, почему абонементы?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

САПР и графика 1`2010