Как и зачем мы анализировали рынок перед созданием маркетплейса лекарств

• Почему маркетплейс вместо интернет-магазина? Зачем аналитика?
• Специализация ИНТЕРВОЛГИ — вертикальная оцифровка фарм-бизнеса
• Структура предпроектной аналитики 
  • 1. Цель проекта
  • 2. Цель документа
  • 3. Экономика
  • 4. Требования
  • 5. Целевая аудитория
  • 6. Конкуренты
  • 7. Функции проекта
  • 8. Данные
  • 9. Карта сайта
  • 10. Технические решения
  • 11. Рекомендации по продвижению
  • 12. Риски
  • 13. Этапы запуска
  • 14. Предварительная смета 
• Заключение

Почему маркетплейс вместо интернет-магазина? Зачем аналитика?

Рынок веб-проектов расслоился на простые сайты (здесь балом правят Tilda, Wix и прочие Битрикс24.Сайты) и ультра-сложные b2b-личные кабинеты дилерских сетей и маркетплейсы (площадки, размещающие товары партнеров, такие как OZON, Беру!, WildBerries). Такие проекты уникальны и в них по определению трудно использовать предыдущий опыт веб-разработки. Нельзя сделать маркетплейс с наскока, даже имея за плечами тысячу успешных интернет-магазинов.

Чтобы не оказаться у разбитого корыта проекта, все заинтересованные лица (в том числе и разработчики) должны сразу задать себе вопрос: понимаем ли мы, кто именно, что именно и как именно будет делать, чтобы проект был успешен?

Если нет ясного представления — нужно не в бой бросаться и не бюджеты со сроками согласовывать, а делать грамотное предпроектное исследование. Оно поможет увидеть главные подводные камни сложной новой разработки. Желательно, чтобы авторы этого исследования участвовали в дальнейшей разработке проекта. Да, мы снова говорим о том, что в ИНТЕРВОЛГЕ не только код пишут, но и решают проблемы бизнеса).

Специализация ИНТЕРВОЛГИ — вертикальная оцифровка фарм-бизнеса

ИНТЕРВОЛГА комплексно автоматизирует процессы в компаниях фармацевтической направленности

У нас за плечами около 20 проектов фарм-отрасли, и мы отлично понимаем особенности бизнеса. 

Летом 2019 года крупная фарм-компания (дистрибьютор, производитель и обладатель собственной аптечной сети) обратилась к нам с идеей разработки интернет-магазина нового поколения — маркетплейса.

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

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

Мы считаем что любой нетривиальный проект должен начинаться с такого исследования. Нормально, если его делают 2 команды вместе — Заказчик и Интегратор.

Структура предпроектной аналитики 

Поделитесь статьей в соцсетях, заполните форму в конце страницы и получите структуру такого исследования в виде отдельного файла.

1. Цель проекта

Ради чего затевается проект? Зачастую это все, что есть на «нулевом» этапе работ. Должна быть измерима, достижима и понятна всем участникам, например «занять {сколько-то}% рынка онлайн-торговли {чем-то} в России к {какому-то} году». Цель может иметь промежуточные вехи, которые помогут заранее понять, попадает проект в ожидания или нет.

2. Цель документа

Зачем нужен этот документ? Понять, кто, что и как будет делать. По сути, цель документа: проработка плана достижения цели проекта.

3. Экономика

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

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

4. Требования

От чего нельзя отказаться для достижения цели проекта? Например: работа сервиса в конкретных городах, бюджет на колл-центр, сколько сотрудников может нанять/выделить для управления? Следует обсудить и описать самое важное: технологическое окружение и интеграции (какие ИТ-системы задействованы в том или ином виде в работе нового проекта), логистика и пути товара. О цвете кнопок и поддерживаемой версии Chrome будет возможность подумать на этапе макетов и ТЗ, сейчас же основные требования — именно по бизнесу.

5. Целевая аудитория

Кто она и чего хочет? Хорошо, если у клиента есть доступ к Google Аналитикс / Яндекс.Метрике проекта похожей тематики. Если нет, то придется выполнить маркетинговое исследование конкурентов (см соответствующий раздел).

Начать анализ можно с сервиса Яндекс Wordstat. Он поможет понять сезонность запросов, а также что именно интересует людей в связи с тем или иным товаром. Например, с названием препарата «анальгин» чаще всего ищут «детям», «можно» и «инструкция», а вовсе не цену. Исходя из потребностей целевой аудитории чуть позже нужно будет продумывать функции и структуру сайта.

6. Конкуренты

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

6.1 Маркетинговый анализ конкурентов

Честный способ получить реальные данные о посещаемости сайтов конкурентов (пусть и с погрешностью) — проект SimilarWeb. В отчете этого сервиса будут источники посещений, возраст, пол и др. — достаточные сведения для предварительного анализа трафика и понимания ЦА в общих чертах. 

Эту работу должен проводить интернет-маркетолог.

6.2 Технический анализ конкурентов

Рекомендуется исследовать скорость загрузки, размер основных страниц конкурентов, баллы по Google PageSpeed Insights. Это даст представление о приемлемом уровне реализации схожих проектов.

Важные вопросы для проектов с большими данными:

1. Есть ли сортировка? По каким полям?

2. Есть ли фильтрация? По каким полям?

3. Есть ли Geo IP и как устроена региональность?

4. Какие браузеры и устройства поддерживаются версткой?

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

Эту работу должен проводить разработчик.

7. Функции проекта

Кто и как будет взаимодействовать с проектом после старта? Результаты анализа конкурентов и потребностей ЦА удобно представить в виде диаграммы прецедентов (UML Use case). Ниже представлен фрагмент такой диаграммы для нашего клиента.

7.1 Роли

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

Бывают технические роли, которые исполняет не какой-то конкретный человек, а веб-сервис или компания-партнер (платежные агенты, службы доставки, СМС-провайдеры, Яндекс.Маркет).

7.2 Действия

Какие действия будут доступны в проекте? Впоследствии они найдут свое отражение в структуре данных и карте сайта.

8. Данные

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

8.1 Сущности

Какие виды данных есть и как они связаны? Выделенные сущности удобно представить в виде ER-диаграммы (диаграммы «сущность-связь»). Это классический подготовительный этап при проектировании баз данных.

8.2 Источники данных

Откуда брать данные? Мало назвать сущности, требуется также решить, как данные будут попадать в проект и откуда. Откуда взять базу клиентов? Базу городов? E-mail’ы для первой рассылки? Следует заполнить таблицу.

Вид данных	Источник	Способ ввода
Город	База ФИАС	Интеграция
Пользователь	Старый сайт	Вручную через импорт CSV (телефон, почта, логин)

8.3 Движение данных

Как будут распределены данные в проекте? Учитывая список сущностей и источники информации нужно представить схему движения данных в проекте. Для этого подойдет диаграмма развертывания (UML Deployment).

9. Карта сайта

Как должен быть устроен сайт чтобы отвечать требованиям ЦА? На этом этапе мы возвращаемся к пунктам исследования Целевая аудитория и Функции проекта и выводим на их основе первичную карту сайта.

ВАЖНО! При разработке ТЗ рекомендуется собрать семантическое ядро, и на его основе спроектировать финальную структуру сайта (в особенности каталога).

10. Технические решения

Какие технические решения стоят за каждым из разделов исследования? Теперь, когда функции и данные определены, можно ответить на технические вопросы. Например:

1. Какие интеграции потребуются в проекте?

2. Как обеспечить актуальность данных?

3. Какие отчеты нужны на сайте?

4. Применим ли умный фильтр?

5. Как должна работать фича Х?

Универсальный список вопросов составить нельзя — они возникают в ходе исследования и зависят от специфики проекта.

11. Рекомендации по продвижению

Как правильно продвигать такой проект? Значительная часть предварительного исследования проводится маркетологом. Уже на этом этапе можно сделать глобальные выводы о стратегии продвижения: как делать контекст, как делать SEO (и надо ли)?  Стоит ли размещать баннеры на сайте? Нужно ли мобильное приложение?

12. Риски

Какие риски есть в проекте и как ими управлять? На этом этапе выполняется отдельное исследование. Вспоминаем PMBOK:

1. Идентификация рисков — определение перечня рисков.

2. Качественный анализ рисков — расстановка приоритетов рисков.

3. (Количественный анализ рисков — численный анализ эффекта рисков, пропускаем на предварительном исследовании)

4. Планирование реагирования на риски — разработка вариантов реагирования

5. Составление плана контроля рисков — определение регламента

Последовательно заполняются таблицы:

Код	Причина	Риск	Эффект
R1	Запланирована большая работа	Срок разработки не устраивает клиента	Проект не будет запущен

Риск	Вероятность (1-10)	Последствия (1-10)	Важность (В*П)
R2	10	10	100

Риск	Стратегия	Основной план	Отходной план
R11	Снижение	Регламентируем время реакции партнерского отдела, разделяем хотелки и вопросы

13. Этапы запуска

Как стартуем проект? Т.к. для простых проектов предварительное исследование не нужно, ответ очевиден: в несколько этапов. Проставив приоритеты функциям проекта нужно составить поэтапный план запуска.

14. Предварительная смета 

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

Заключение

Провести подобное исследование реально за 60-100 часов, но требуется комплексная работа разных специалистов: проектировщика, маркетолога и разработчика. У нас есть квалифицированные сотрудники и 15-летний опыт веб-разработки. 

ИНТЕРВОЛГА имеет все возможности для анализа рынка, проектирования решения, веб-маркетинга и аналитики, а затем разработки и запуска проекта по e-commercе и автоматизации внутренних проектов. Задумали сложный проект? Ищете отраслевую экспертизу? Напишите нам: Фудтех, Фарма, Логистика.

Вам может быть интересно:

Разработка и запуск маркетплейса

Больше информации про интранет-системы в нашем телеграм-канале:  https://t.me/r4intranet.