P&L — от отчёта к инструменту поиска проблем
Финансовый отчёт, который не просто показывает прибыль, а подсказывает, где искать проблему
Команда
Product Designer (я)
•
Product Manager
•
Front‑End
•
Back‑End
•
QA
Результат
+30%
Retention 2W
+20%
Sales
Контекст
Когда я пришёл в компанию, Hub только начинали делать — собственную ERP для селлеров маркетплейсов, способную заменить МойСклад в связке с первым продуктом компании Connect
Hub
EPR‑система заточенная под нужды селлеров на маркетплейсах
Connect
Сервис, позволяющий сихнронизировать данные между ERP и маркетплейсом
МойСклад
ERP‑система, с которой изначально работал сервис Connect как доп. модуль
К моменту задачи товары, документы и склад в Hub уже работали. Дальше — отчёты. Одним из ключевых отчетов являлся P&L
Важность P&L‑отчёта
01
Данные, которые Hub ежедневно получает и хранит, превращаются в основу для финансовых решений пользователя
02
Он собирает результат работы всей системы в одном месте
03
Хороший P&L должен был дать пользователю причину выбрать Hub вместо привычного МойСклад
Задача
Создать отчёт P&L, который станет конкурентным преимуществом перед системой МойСклад
«У нас тоже есть P&L» ≠ «Зачем мне переходить на Hub?»
Таблица отвечала не на тот вопрос
P&L МойСклад, 1С и Excel‑шаблоны  — это в основном таблица
Она хорошо отвечает на вопрос «какие у меня показатели» и заметно хуже — на «куда мне смотреть в первую очередь»
Первая гипотеза
Ускорить чтение данных с помощью визуализации.
Исследование
Сегментация по обороту:
до 10 млн ₽/мес
10‑100 млн ₽/мес
100+ млн ₽/мес
Участники:
Клиенты Connect+МойСклад
Селлеры Topseller Club
Вопросы исследования:
Когда открывают P&L?
Какие решения принимают?
Как сравнивают результаты?
Чего не хватает?
Как исследование повлияло на гипотезы
Было
Пользователи хотят быстрее анализировать один период
Графики — дополнение к таблице
План — доработать текущий P&L
Стало
Пользователи приходят сравнивать периоды
Графики нужны для поиска отклонений
Часть идей требует изменить саму модель данных
Неожиданная находка
Несколько пользователей независимо друг от друга делали это вручную: перестроить отчёт, выписать цифры, сопоставить. Сравнение периодов стало приоритетом №1
Перед реализацией нового P&L, сначала пришлось изменить способ учета расходов
Суть проблемы:
После интервью появилась новая гипотеза: пользователям важно не только видеть сумму расходов, но и понимать, из чего она складывается.
Однако, реализовать детализацию оказалось невозможно, потому что дополнительные расходы вели бессистемно
Каждый пользователь:
  • Создавал собственные поля
  • Называл их по‑разному
  • Учитывал расходы по своему сценарию
Из‑за этого система не могла корректно агрегировать расходы
Пример:
Я получил возврат товара на склад. И чтобы его снова продать, нужно сделать переупаковку товара, которая требует затрат
Первый пользователь:
01－ Перехожу в документ
02 － Нахожу/создаю доп. поле “Доп. расход”
03－ Указываю там значение “500”
Второй пользователь:
01－ Перехожу в документ
02－ Нахожу/создаю доп. поле “Упаковка”
03－ Указываю там значение “500”
Третий пользователь:
01－ Не указал расход вовсе, ибо не нашел нужного поля
Как итог
Нельзя корректно детализировать расходы
2 варианта: где хранить расходы
Дополнительные поля:
Не нужно ничего разрабатывать
Пользователи уже знакомы с подходом
Каждый ведет учёт по‑своему
Расходы невозможно стандартизировать
Отчёты остаются ограничеными
Детализация расходов невозможна
Отдельная сущность для доходов и расходов:
Единая структура данных
Готовый справочник популярных статьей
Возможность добавлять свои статьи
Данные становятся пригодны для аналитики
Можно строить новые отчёты
Выше стоимость разработки
Требуется доработать модель документов
Почему это было верно:
Снижает порог входа — справочник уже заполнен
Не ограничивает сложные сценарии — свои статьи доступны
Даёт единый формат — отчёты считаются предсказуемо
Становится основой — пригодилась не только P&L, но и другим модулям, и API
Решение 1
Новый сценарий учёта расходов
Было: создать поле → придумать название → следить за единообразием самому → указать сумму

Стало: создать документ → выбрать статью → указать сумму

Расход на товар добавляется к строке товара. Расход на весь документ — в раздел расходов. Если нужной статьи нет, пользователь создаёт её в справочнике
Решение 2
Один экран, четыре сценария
Сравнение периодов, график динамики, таблица, детализация расходов

Принцип — от общего к частному:
  • Обзор — что изменилось? (график)
  • Отклонение — что требует внимания? (показатель)
  • Детализация — из чего это состоит? (структура)

Графики не заменяют таблицу, они показывают, где в таблице искать
Решение 3
Сравнение нескольких периодов
Например, Q1 2025, Q2 2025, Q3 2025, Q4 2024 — селлер сопоставляет моменты, когда менялась стратегия бизнеса
Решение 4
Два типа графика под разные задачи
Stacked Bar Chart — сравнение периодов, состав показателя, точное значение по наведению
Pie Chart — структура расходов: соотношение категорий без перегрузки таблицы
Ограничения
Библиотека графиков
Графики строились на ng2‑charts. Собственную визуализацию не создавали — выбрали подходящие типы из библиотеки и адаптировали под дизайн‑систему
Клик по графику
Планировали сделать клик по показателю переходом к строке таблицы. Библиотека не позволяла это без дополнительной разработки, стоимость оценили и решили не тратить на это ресурс. Ценность графика — быстро найти зону, которая требует внимания, — сохранилась и без этого перехода
Не прошло валидацию
Таблицу не перестраивали
Хотели сделать таблицу компактнее. Исследование показало: пользователи привыкли к её структуре и используют для детального анализа. Решили не менять фундаментальную структуру, а часть аналитической нагрузки вынесли в графики
Проверка и итерация
Проверили
QA (расход на товар, на документ, статьи, распределение), затем 30 селлеров в бете на своих данных, без спецзаданий
Нашли
Проблемы в расчётах по ходу реальной работы
Изменили
Дорабатывали серверную часть, перепроверяли результат
Проверили
Поведение метрики «Time On Page»
Нашли
Причина — P&L долго считался на сервере: пользователь обновлял страницу, расчёт начинался заново
Изменили
Разделили расчёт на горячий и холодный
Результат
+30% — удержание новых пользователей за 2 недели
Сравнение: Connect + Hub и Connect + МойСклад, новые регистрации
+20% — продажи Connect + Hub
Сопоставимый период после релиза, данные отдела продаж
Новая модель учёта
Продажи показывали P&L клиентам как довод в пользу Hub
Коммерческое применение
Продажи показывали P&L клиентам как довод в пользу Hub
Ограничение интерпретации
Retention и продажи отражают изменения на уровне продукта и связки сервисов, а не изолированный эффект P&L. Поведенческой аналитики самого отчёта на момент релиза не было (семантическая разметка расширялась постепенно)
Что сделал бы иначе
Аномалии и рекомендации.
Например, расходы на Яндекс Маркет выросли на 33% при росте выручки на 4%. Система показывает: что произошло, что проверить (комиссии, логистика, реклама), какое действие сделать (открыть детализацию)
Проверка качества данных
Зарплата — 0 ₽ — сигнал, что расход не ведётся. Подсказка: «Добавьте расходы на зарплату, чтобы получить точный расчёт прибыли». При неполных данных система не может честно обещать пользователю реальную прибыль
Периоды без модальных окон
Сейчас добавление и редактирование периода завязано на модальные окна. Дальше — редактирование прямо в рабочей области
+7(927)623‑11‑14
t.me/balladdesign
balladdesign@gmail.com
Made on
Tilda