Прошел первый год работы компании Прогноз «в новых условиях», целесообразно подвести итоги, определить планы на второй год. Для этих целей приведены результаты маркетингового экспресс – анализа ситуации:
Анализ состояния компании на август 2017 года
1. Компания Прогноз в период 2010-2016 годы имела дивизиональную организационную структуру (дивизион представлял законченную бизнес-единицу со своей клиентской базой, разработчиками и т.д.), в которой были департаменты, специализированные по отдельным направлениям: разработка инвестиционного ПО (базовая платформа бизнес-аналитики) и разработка заказного ПО (банковский сектор, нефте-газ, гос. сектор, ОПК).
В этих двух группах департаментов были созданы различные бизнес-процессы, соответствующие циклам разработка-продвижение-продажи инвестиционного и заказного ПО. Сами эти бизнес-процессы не были формализованы.
В условиях, когда более 90% доходов компании приносили заказные разработки ПО для конкретных клиентов, департаменты разработки заказного ПО, на основе базовой платформы бизнес-аналитики, чувствовали «свою самостоятельность», что вносило известные риски в рабочий процесс компании. Эти риски усиливались отсутствием в компании адекватной системы лояльности и мотивации ключевых специалистов и ТОРов (например, фиксирование служебных произведений и премиальные выплаты).
2. Клиентская база генерировалась высоким имиджем компании на мировом и российском рынках (магический квадрат Gartner), активными публикациями в Интернет и на сайте компании (более 20 публикаций ежегодно), статьями в тематических и отраслевых журналах, рекламными компаниями и акциями. Для перевода холодных клиентов в теплые и горячие использовался штат сейлов из коммерческого отдела компании, в помощь которым предоставлялись пресейлы - разработчики из департаментов разработки заказного ПО.
3. Партнерская сеть компании была слабо развита и включала менее 10 системных интеграторов в разных отраслях промышленности и регионах РФ. Не было концепции партнерской сети, не были внедрены программы лояльности и мотивации партнеров и меры по снижению/исключению конкуренции между партнерами. Поскольку департаменты компании представляли законченные бизнес-единицы, они тоже самостоятельно присутствовали на рынке, и нередко перехватывали заказы внешних системных интеграторов (была конкуренция между партнерами в собственной партнерской сети).
4. Партнеры-системные интеграторы, как правило, самостоятельно искали клиентов и выполняли полный комплекс работ по заключению и выполнению Договоров (разработка рекламных акций и скриптов продаж; выполнение презентации продукта, нацеленной на конкретного клиента; презентации демоверсий продукта; разработка концепции внедрения продукта у конкретного клиента (решаемые бизнес и функциональные задачи клиента, экономический эффект внедрения продукта, формы рабочих столов операторов и т.п.); разработка технико-коммерческого предложения на базе «Концепции продукта», которую получали от разработчиков вендора; разработка ТЗ и Договора, выполнение системной интеграции при консультациях с вендором, внедрение продукта на объекте клиента и послепродажное обслуживание.
5. Можно допустить, что описанная в п.п. 1 и 3 организация работ в компании-вендоре и в партнерской сети, инициировали снижение устойчивости общего бизнеса компании-вендора, которое, в условиях резкого отрицательного скачка курса рубля в декабре 2014 года и валютных кредитов (МВФ) вендора, могла инициировать «внешние» финансовые проблемы в компании Прогноз.
Эти финансовые проблемы, в условиях, когда ключевые специалисты компании не были достаточно мотивированы на работу в компании, инициировали в 2015-2016 годах уход из компании целых подразделений разработки заказного ПО со своими клиентскими базами, техническими наработками и сработанными командами разработчиков.
6. В результате описанных событий, на ноябрь 2016 года, в компании-вендоре, из подразделений разработчиков, сохранился только департамент разработчиков (около 250 человек), который имел опыт разработки базовой платформы бизнес-аналитики (некоторых отраслевых решений?).
То есть, в течение последних 12 месяцев, основной штат разработчиков компании имел опыт выполнения разработки инвестиционного ПО и не имел опыта разработки заказного ПО (продукт под конкретного клиента).
В тоже время, из СМИ следует, что в течение последних 12 месяцев, усилия новых ТОРов компании были направлены, прежде всего, на создание партнерской сети на основе системных интеграторов, а не на создание собственных подразделений разработки-продвижения-продажи заказного ПО и продажи этого заказного ПО конечному клиенту.
Можно допустить, что такие приоритеты привели в тому, что на ноябрь 2017 года, фактически в условиях стартапа-2017 (и компании и продукта), основной бизнес-процесс компании настроен на разработку базовой платформы бизнес-аналитики (в «голом» виде практически не востребована на рынке), по схеме разработки инвестиционного ПО с финансированием из собственных средств компании (этот бизнес-процесс не формализован). А бизнес-процесс разработки заказного ПО в компании, который приносил основной дохода, за 12 последних месяцев, так и не создан.
Очевидно, что в условиях, когда в компании отсутствует бизнес-процесс «разработка-продвижение-продажи заказного ПО», по которому ранее компания получала до 90% доходов, затруднительно вывести компанию в прибыльный режим работы.
Предложения* по выводу компании в прибыльный режим работы
1. В вышеописанной ситуации ноября 2016 года, апробированным путем вывода компании в прибыльный режим работы, было бы создание новых подразделений по разработке заказного ПО, и каналов его продвижения и продаж в компании-вендоре. Такое решение являлось бы коммерчески оправданным, так как структура цены заказного ПО компании, примерно, на 50% состоит из стоимости базовой платформы и на 50 % из стоимости работ по настойке и адаптации под конкретного клиента. И в период до 2014 года, продажа такого заказного ПО приносила компании-вендору до 90% доходов.
Разработка собственного заказного ПО и прямые продажи его на рынке позволили бы сформировать, новый имидж компании, сгенерировать холодных/теплых клиентов, заинтересовать системных интеграторов, желающих стать участниками партнерской сети вендора.
Обоснованность такого решения следует их опыта российских и мировых компаний, которые, после разработки базовых платформ, организовывали собственный бизнес-процесс по разработке-продвижению-продажам заказного ПО. И только после формирования имиджа компании на рынке, успешных продаж заказного ПО многочисленым клиентам, наработки партнерских отношений с компаниями – потенциальными участниками партнерской сети, и набора достаточно портфеля заказов, - принималось решение о создании партнерской сети: рынок продукта был подготовлен для вывода на него партнерской сети вендора. Нарушение этой последовательности работ, с большой вероятностью, может привести, как к отсутствию конечных клиентов, так и отсутствию системных/программных интеграторов, считающих свой бизнес, коммерчески оправданным, в партнерской сети компании-вендора.
2. В ситуации ноября 2017 года, задача вывода компании в прибыльный режим работы может быть решена по двум апробированным сценариям:
• организация собственной разработки заказного ПО в вендоре,
• привлечение внешнего системного/программного интегратора, имеющего опыт работы с данной платформой бизнес-аналитики (договор с конечным клиентом на поставку-настройку-ввод в эксплуатацию-постпродажное обслуживание - заключает вендор и берет на подряд «надежную» стороннюю ИТ-компанию для разработки заказного ПО по ТЗ и Договору, подписанными конечным клиентом).
Выбор сценариев определяется их стоимостью, требуемыми ресурсами, рисками, перспективами использования ИТ-подрядчика, в качестве партнера, на значимых сегментах ИТ-рынка и т.п. На сценарий и инструменты вывода компании-вендора в прибыльный режим также влияет «настоящий статус» компании. Например, если в компании в течение более 12 месяцев «не было» продаж ИТ-продукта, то целесообразно использовать методологию и инструменты стартапа, см. ПРИЛОЖЕНИЕ 1.
*Примечание: настоящие выводы и предложения получены на базе ограниченной информации из СМИ и требует уточнения.
Представленный материал подготовлен маркетологом MBA (MS, ЛК, IDC) при консультациях с профессионалами связи, является авторским, ссылка обязательна.
С уважением,
Alex Rail,
16.11.2017
ПРИЛОЖЕНИЕ 1
Организация работ при стартапе производителя ПО.
Определение модели настоящего состояния производителя ПО.
Если допустить, что в последние 12 месяц состояние компании-вендора «оказалось замороженным», для вывода компании в прибыльный режим работы, целесообразно оценить её настоящее состояние и определить реальные цели и инструменты их достижения.
Определение модели настоящего состояния компании, например:
• отсутствует (имеется) положительный имидж компании, холодные/теплые клиенты (даже при скидках до 50% для коммерческих компаний и «интересах» для гос. компаний); отсутствуют партнеры-системные/программные интеграторы для создания партнерской сети компании-вендора.
• отсутствует (имеется) основной рыночный продукт-заказное ПО для конечного клиента.
• не сформированы команды разработчиков (по 6-8 человек) для разработки-продвижения заказного ПО на базе платформы бизнес-аналитики.
• отсутствует формализованный бизнес-процесс разработки ПО (затрудняет управляемость компании и интеграцию работ с ИТ-партнерами).
• отсутствуют специалисты, имеющие интегрированный опыт разработки-продвижения-продажи ПО на конкурентных рынках.
• отсутствуют подготовленные специалисты для выполнения стартапа производителя ПО на рынок B2B,
• имеются разработчики инвестиционного ПО (базовая платформа бизнес-аналитики), работающие в условиях не формализованного бизнес-процесса,
• имеются специалисты с опытом работы в производителе ПО (рынок B2B) при отлаженной коммерческой деятельности компании.
При таких исходных данных: настоящее состояние компании – стартап производителя ПО на рынке B2B России через стартап нового заказного ПО на базе собственной платформы бизнес-аналитики.
Порядок выполнения стартапа программного продукта на конкурентный рынок.
ИТ-стартап требует особой организации работ, отличной от отлаженного коммерческого процесса производителя ПО. Из мирового опыта следует, что отсутствие адекватной организации работ, при стартапе, приводит к «ненужному» использованию 80% производственных сил и времени. Для уменьшения таких потерь сегодня в мире разработаны методологии выполнения стартапа, которые могут быть реализованы подготовленными специалистами. Прежде всего, это:
• лидер ИТ-стартапа А – вывод новой компании производителя ПО на российский рынок B2B через запуск коммерческих продаж и доведения их объемов до уровня, обеспечивающего окупаемость инвестиций,
• лидер ИТ-стартапа В – вывод нового ИТ-продукта на российский конкурентный рынка B2B.
Ниже приводиться типовой порядок выполнения стартапа нового программного продукта на конкурентный рынок (см. рекомендации ФРИИ РФ и курс лекций Питер Тель «Стартап», Стенфорд):
Первый этап: Определение востребованности рынком ценностного предложения по новому программному продукту через исследования клиентов.
(должны быть получены ответы на вопросы: Кто они? Почему покупают? Где их искать? Как и по каким каналам ими можно управлять?)
1. Ценностное предложение.
2. Подтверждение ценности через опросы клиентов в целевой аудитории.
3. Укрупненное бизнес-планирование: объем целевого рынка, модель цены, издержки, доходы.
4. Разработка модели минимально жизнеспособного продукта – MVP.
5. Разработка продукта по модели MVP.
6. Поиск клиентов, общение и изучение их проблем, сбор отзывов о модели продукта MVP, доработка ПО.
7. Выпуск опытной партии ПО.
8. Первые продажи продукта (бонусные программы), сбор отзывов покупателей о продукте, доработка ПО.
Второй этап: Определение целевой аудитории и каналов продажи нового ИТ-продукта, обеспечивающих окупаемость затрат и прибыль.
1. Определение объемов целевых рынков, целевой аудитории, портрета клиента.
2. Ценностное предложение для конкретной целевой аудитории.
3. Привлечение клиентов: статьи в отраслевых и тематических журналах, маркетинговые компании и акции, интернет-маркетинг.
4. Разработка модели MVP для конкретной целевой аудитории.
5. Первые продажи (бонусы), опросы покупателей, определение недоработок, учет проблем внедрения и поддержки.
6. Доработка модели MVP с учетом пожеланий первых покупателей, с целью расширения целевой аудитории продукта.
7. Формирование стабильного потока продаж программного продукта в объемах, обеспечивающих окупаемость затрат на его разработку и вывод на рынок.
