B2B-портал как MVP: минимальный скоуп через аудит данных и процессов

Почему аудит данных решает судьбу MVP

Вы запускаете B2B-портал, чтобы клиенты оформляли заказы сами, а менеджеры перестали тратить 60% времени на уточнения по телефону и email. Разработчик называет срок 3–4 месяца и бюджет 2–4 млн рублей. Вы фиксируете скоуп: каталог, корзина, личный кабинет, интеграция с 1С. Через месяц после старта разработки выясняется: в 1С 15% контрагентов задвоены по ИНН, у 30% SKU нет актуальных остатков, а индивидуальные прайсы менеджеры ведут в своих Excel-файлах. Data-cleanup съедает 40% бюджета и сдвигает запуск на два месяца. Клиенты, приглашённые на пилот, видят неверные цены и теряют доверие.

Этот сценарий — не гипотетический. По данным Gartner, 70% проектов интеграции ERP с порталами выходят за рамки бюджета именно из-за недооценки качества данных. Проблема не в разработке, а в том, что аудит данных и процессов провели после фиксации скоупа, а не до.

Аудит за 5 дней меняет порядок действий: сначала вы диагностируете источник данных, затем на основе реальной картины определяете минимально достаточный набор функций MVP. Так вы управляете рисками бюджета и сроков, а не реагируете на сюрпризы.

Чеклист аудита данных за 5 дней

Сфокусируйтесь на четырёх блоках, критичных для любого B2B-портала. Каждый блок — один рабочий день аналитика или руководителя проекта с доступом к 1С и опросом менеджеров.

День 1. Контрагенты

• Выгрузите всех контрагентов с ИНН, КПП, юридическим адресом, контактным лицом.
• Проверьте дубли по ИНН: сколько записей с одинаковым ИНН, но разными наименованиями или кодами в 1С.
• Оцените полноту реквизитов: у скольких контрагентов отсутствует ИНН, телефон или email для авторизации.
• Зафиксируйте метрику: % контрагентов с дублями по ИНН. Порог тревоги — >5%.

День 2. Номенклатура

• Выгрузите активные SKU (товары/услуги, по которым были движения за последние 12 месяцев).
• Проверьте наличие артикула, наименования, единицы измерения, фото и описания.
• Найдите дубли по артикулу: один и тот же товар заведён дважды под разными кодами.
• Зафиксируйте метрику: % SKU без фото или описания (важно для каталога) и % дублей артикулов.

День 3. Ценообразование

• Выгрузите все действующие договоры с индивидуальными ценами (типовые соглашения в 1С).
• Сравните с фактическими ценами отгрузки за последний квартал: есть ли расхождения.
• Опросите 3–5 менеджеров: ведут ли они прайсы в Excel, потому что «в 1С неудобно» или «цены часто меняются».
• Зафиксируйте метрику: % индивидуальных прайсов, хранящихся вне 1С. Если >10% — это стоп-сигнал.

День 4. Остатки и статусы заказов

• Проверьте актуальность остатков: запросите у склада реальный остаток по 20–30 ходовым позициям и сравните с данными 1С.
• Оцените, сколько заказов имеют статус «Отгружен», но фактически ещё в пути (разрыв данных).
• Определите источник правды: 1С, складская система или ручной учёт.
• Зафиксируйте метрику: % SKU с расхождением остатка >10% между 1С и фактом.

День 5. Сводка и светофор

• Сведите метрики в таблицу и присвойте уровень готовности по каждому блоку (см. раздел «Светофор готовности»).
• Подготовьте отчёт для ЛПР: объём ручного труда, который портал может убрать, и риски, которые必须先 устранить.

Методологию аудита данных из 1С по четырём измерениям (полнота, дубли, консистентность, свежесть) мы детально разбирали в статье «Качество данных перед внедрением ИИ: минимальный аудит за неделю». Здесь применяем её к специфике B2B-портала.

Матрица приоритетов: от ручного труда к скоупу

Параллельно с аудитом данных оцените, какие процессы создают наибольшую операционную нагрузку. Это даст объективный приоритет для MVP, а не wishlist стейкхолдеров.

Соберите данные за месяц по каждому процессу, связанному с обработкой заказов:

FTE-часы × стоимость часа менеджера (например, 600 ₽) дают прямую экономию. Частота ошибок × стоимость ошибки — косвенную. Процессы с высокой зависимостью от качества данных нельзя автоматизировать в MVP, пока данные не очищены.

В примере выше приоритет MVP — приём заказа и уточнение цены/наличия. Но если аудит показал, что 20% индивидуальных прайсов живут вне 1С, блок «Уточнение цены» получит жёлтый сигнал: его можно включить в скоуп только для тех контрагентов, чьи цены уже в ERP.

Светофор готовности: когда запускать, а когда чистить

На основе метрик аудита присвойте каждому блоку цвет и примите решение о скоупе MVP.

Зелёный — запускаем полный MVP

• Дубли контрагентов по ИНН <3%
• Полнота реквизитов >95% (ИНН, email)
• SKU без фото/описания <10%
• Расхождение остатков <5%
• Индивидуальные прайсы вне 1С <5%

Жёлтый — MVP с ограниченным скоупом

• Дубли контрагентов 3–10%
• Полнота реквизитов 80–95%
• SKU без фото/описания 10–30%
• Расхождение остатков 5–15%
• Индивидуальные прайсы вне 1С 5–15%

Действие: исключаем из MVP функции, критично зависящие от грязных данных. Например, не показываем онлайн-остатки, если расхождение >10%. Не включаем индивидуальные цены для контрагентов, чьи прайсы не в 1С. Запускаем пилот на ограниченной группе клиентов с чистыми данными.

Красный — data-cleanup sprint перед MVP

• Дубли контрагентов >10%
• Полнота реквизитов <80%
• SKU без описания >30%
• Расхождение остатков >15%
• Индивидуальные прайсы вне 1С >15%

Действие: выделите 2–3 недели на очистку данных силами 1–2 аналитиков и ответственных менеджеров. Без этого портал принесёт больше рекламаций, чем пользы. Типичный объём работ: дедупликация контрагентов, заведение недостающих реквизитов, перенос прайсов из Excel в 1С, выверка остатков по складу.

Baseline-карточка: зафиксировать до старта

Чтобы после запуска MVP доказать ROI, зафиксируйте текущее состояние по четырём метрикам. Без baseline любые улучшения будут выглядеть как субъективное «стало лучше».

Шаблон baseline-карточки (заполните до начала разработки):

Через 4–8 недель после запуска MVP замерьте те же метрики и сравните. Целевые бенчмарки для пилотной группы:

• % заказов через портал: 50–70%
• Снижение входящих запросов на статус заказа: на 40–60% от baseline
• Время от заявки до счёта: <30 минут
• Доля заказов с ошибкой: <2% (стремится к 0 по ценообразованию)

Anti-patterns: три ошибки, которые стоят бюджета

Ошибка 1. Скоуп MVP формируется через wishlist стейкхолдеров Коммерческий директор хочет «полный каталог с персонализацией», IT — «микросервисную архитектуру», маркетинг — «интеграцию с CRM». Без привязки к объёму ручного труда и качеству данных первый релиз не устраняет реальный bottleneck. Результат: портал запущен, но менеджеры продолжают обрабатывать заказы вручную, потому что клиенты не доверяют ценам на сайте.

Ошибка 2. Интеграция с 1С оценивается как чекбокс в ТЗ В техническом задании пишут «интеграция с 1С: обмен заказами, остатками, ценами». Без анализа чистоты мастер-данных эта строчка превращается в data-cleanup sprint уже после старта разработки, съедая 30–50% бюджета. Решение: до написания ТЗ проведите аудит по чеклисту выше и заложите время на очистку данных в отдельный этап.

Ошибка 3. KPI портала не фиксируются до запуска Команда отчитывается: «Портал запущен, зарегистрировано 50 клиентов». Но без baseline невозможно доказать, что время обработки заказа сократилось с 4,5 часов до 20 минут, а доля ошибок упала с 11% до 1%. Проект воспринимается как затраты, а не инвестиция. Решение: baseline-карточка — обязательный артефакт этапа discovery.

Мини-кейс: дистрибьютор с 200 партнёрами

Региональный дистрибьютор автокомпонентов, 200+ активных партнёров, 12 менеджеров по продажам. Проблема: менеджеры тратили 60% времени на уточнение цен и наличия по телефону, 15% заказов содержали ошибки в артикулах, время от заявки до счёта — до 6 часов.

Аудит данных за 5 дней выявил:

• 8% контрагентов — дубли по ИНН (жёлтый)
• 25% SKU без фото и описания (жёлтый)
• 18% индивидуальных прайсов велись в Excel у менеджеров (красный)
• Расхождение остатков по складу — 12% (жёлтый)

Решение по светофору: красный по ценам → data-cleanup sprint на 2 недели. Два аналитика и старший менеджер перенесли все индивидуальные прайсы в 1С, дедуплицировали контрагентов, выверили остатки по топ-200 позициям.

Скоуп MVP (после очистки):

• Каталог с фото и описаниями только для топ-500 SKU (остальные — без фото)
• Корзина и оформление заказа
• Онлайн-остатки только по выверенным позициям
• Цены из 1С для всех контрагентов (после переноса прайсов)
• Исключено: онлайн-статусы заказов (данные не готовы), полная номенклатура (отложено до второго релиза)

Результаты через 6 недель после запуска пилота на 40 партнёрах:

• 65% заказов стали поступать через портал
• Время от заявки до счёта сократилось до 12 минут
• Доля заказов с ошибкой упала до 1,5%
• Менеджеры высвободили 90 часов в месяц, переключившись на развитие отношений с ключевыми клиентами

FAQ: интеграция с 1С — это сколько времени и денег?

Ответ зависит от трёх факторов: чистоты данных, сложности логики ценообразования и выбранного режима интеграции.

Типология сложности:

• Batch-обмен (раз в 15–30 минут). Подходит для MVP, если допустима задержка в актуализации остатков. Стоимость: 150–300 тыс. ₽, срок: 2–3 недели при зелёном уровне данных.
• Real-time (по запросу). Требует чистых данных и стабильного API 1С. Стоимость: 300–600 тыс. ₽, срок: 3–5 недель. Риск: если в 1С много исключений (индивидуальные скидки, сложные цепочки согласования), срок вырастает вдвое.
• Event-driven (событийная модель). Для высоконагруженных порталов с персонализацией. Стоимость: от 600 тыс. ₽, срок: 6–10 недель. Требует зрелых данных и выделенной команды.

Главный драйвер стоимости — не режим, а чистка данных. При красном уровне аудита даже batch-интеграция может занять 2–3 месяца, потому что 80% времени уйдёт на нормализацию справочников.

Что дальше: от аудита к скоупу первого релиза

Когда аудит пройден и светофор показывает зелёный или жёлтый, вы готовы определить конкретный набор функций MVP. Здесь вступает в силу другой вопрос: «Что именно строить первым, чтобы не переплатить за ненужные фичи?». Подробный decision tree по выбору скоупа первого релиза, включая приоритизацию по бизнес-ценности и технологической сложности, мы разобрали в статье «B2B-портал как MVP: что запускать первым, чтобы не переплатить». Используйте её как следующий шаг после того, как данные и процессы прошли входной фильтр.

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

Для производственных компаний, рассматривающих портал как часть цифровизации цепочки поставок, рекомендуем ознакомиться с операционным playbook «Small Language Models на производстве: от данных до production» — он описывает, как встроить ИИ-инструменты в контур после запуска базового портала.