Рождение ISV продукта

В прошлой статье мы рассмотрели разные типы партнеров: ISV и VAR. Также узнали, что Microsoft хочет видеть партнерскую модель именно в таком виде, но есть некоторые ограничения.

В данной статье мы попробуем рассмотреть данные ограничения несколько детальнее. Начнем с необходимости сохранять интеллектуальную собственность – ISV продукты. Данную проблему решают несколькими способами:

Официальный способ заключается в лицензировании диапазона. Как известно все объекты в Dynamics NAV имеют идентификатор (поле типа Integer) и условно разбиваются на следующие группы:

1..9999 – самое ядро. То, что называется версия W1. Создавать новые объекты в этом диапазоне могут только в штаб квартире Microsoft.

10000..49999 – диапазон локализации. Именно здесь оказываются результаты творчества российского центра разработки и других партнеров по локализации.

50000..99999 – клиентский диапазон (при условии, что клиент купил соответствующие гранулы).

10000000..99999999 – партнерские решения (некоторые партнерские решения стали частью стандарта, например Производство, но нумерацию не изменили).

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

Хотя обе эти сложности при желании можно обойти.

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

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

1. Вынести часть добавленной стоимости во внешние библиотеки (например, так работает DataDirector и интерфейс кассира в LS Retail, Jet Reports и толпа аддонов интегрирующих NAV с WEB).

Как показывает практика это довольно надежный способ. Во-первых, присваивать код технически сложнее (а значит дороже). Во-вторых, знание Visual Studio, SQL, C#, SharePoint - не то чем может похвастаться большинство VAR партнеров. А держать в своем штате выделенного специалиста оказывается экономически не эффективно. Собственно к этой модели Microsoft склоняет партнеров, предоставляя такие механизмы как web службы, дополнительные компоненты, .NET Interop - устоять практически невозможно.

2. Низкая стоимость аддона. Обычно используется для массовых аддонов/утилит, которые нужны всем независимо от отрасли. Т.е. стоимость должна быть такой, чтобы в дилемме “покупать или производить” выбор был на стороне Покупать.

В России данный рынок не развит, потому как пока массовостью Dynamics NAV похвастаться не может, а значит продавать RTC вариант счета-фактуры за х00 рублей нельзя. Если задать стоимость в х000, то чаша весов может переместиться в сторону «Производить».

Стоит отметить, что для примитивных аддонов крайне непросто работает стандартная процедура расширения клиентской лицензии. Теоретически для покупки любого аддона, клиент должен обращаться к своему партнеру, чтобы последний обновил лицензию, заключил контракт с ISV партнером и т.д. За х00 рублей желающих написать лишнее письмо крайне не много, не говоря уже о заключении контракта. Поэтому чаще всего клиент взаимодействует с ISV партнером напрямую, сообщая ему свободный диапазон объектов, а ISV поставляет объекты в доступном для клиента диапазоне.

3. В данном случае ключевым отличием является количество полезного функционала. Т.е. опять-таки эффективность (функциональность/стоимость). Примерами являются LS Retail, где кроме интерфейса кассира и механизма репликации накручены горы полезностей (ценообразование, распределенные базы, отчетность). Вторым примером может быть Incadea, где содержатся залежи функционала связанного с автобизнесом. Это кстати и есть вариант классического ISV продукта. Много полезного и сложного кода, который трудно повторить, дешевле купить. Плюс сопровождение, развитие, методологии внедрения и много чего полезного. Из-за серьезной стоимости и объема модификаций данный продукт проходит по стандартной процедуре расширения клиентской лицензии.

Как же появляются ISV продукты. Есть устойчивое мнение, что в результате стечения обстоятельств и везения. Все начинается с того, что клиент соглашается на разработку решения на базе Dynamics NAV. Внимание – не внедрения и адаптации, а разработку (это разные деньги). Причины могут быть разными - отсутствием альтернатив на рынке (функциональность/цена) или успешной работе отдела продаж.

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

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

Внимание: между клиентским решением и ISV продуктом – качественная пропасть. Причина – разные цели. При создании клиентского решения в первую очередь решаются проблемы конкретного клиента, система «затачивается» под клиентские бизнес-процессы (не всегда правильные), оптимизируется под доступный персонал клиента (иногда слишком умный, иногда не слишком сообразительный). При создании ISV продукта задача – массовая продажа. Поэтому набор поддерживаемых процессов, их вариативность и гибкость увеличивается. (Здесь скрывается один из парадоксов: удовлетворенность клиента ISV продуктом может быть ниже, чем клиентским решением, хотя функционально и качественно ISV продукт сильно опережает клиентское решение). Более того настоящим клиентом для ISV партнера являются другие партнеры. А они будут использовать продукт несколько иначе, чем типовой заказчик – они будут этот продукт внедрять.

Проблемы

Чаще всего звезды не так благосклонны поэтому “вертикальное решение” появляется только в маркетинговых материалах.

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

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

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

Другая проблема – кто будет собирать «коробку». Как было сказано ранее, у партнера наработана экспертиза, которая материализована в виде нескольких клиентских решений и какой-то документации к ним. Далее нужны толковые парни, чтобы пропустить наработки через мозг и создать продукт. И здесь проявляется конфликт – с одной стороны эти люди являются классными экспертами (для создания ISV продукта нужны именно классные эксперты), которых руководство компании спит и видит на внешних заказах в процессе зарабатывания денег для компании. С другой стороны на внутренних проектах часто хромает мотивация, в результате сами специалисты тоже предпочитают видеть себя на внешних заказах. Часто сотрудники на внутренние проекты выделяют по остаточному принципу, иногда пытаются решить проблему недостатка ресурсов за счет стажеров. В результате текучка кадров, затягивание проекта, часто случаются остановки. Шансы на успешное создание продукта стремительно тают.

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

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

Одним качественным программированием к сожалению ограничиться нельзя. Далее следует подготовить документацию, пройти сертификацию решения в Microsoft. И с головой погрузиться в работу над продвижением ISV продукта (маркетинговые материалы, ценовая политика, партнерский канал). Как показывает ситуация на рынке программного обеспечения, часто самым прибыльным оказывается не тот, кто создал сверх технологичный и полезный продукт, а тот кто отлично продает (к сожалению иногда это оказываются продукты довольно среднего качества).
Параллельно с продвижением решения следует обеспечивать качественную поддержку и готовить следующую версию. Ибо как говорил товарищ Спольски – только «огонь и движение» позволяют оторваться от конкурентов.

Метки: ,



Оставьте свой отзыв!