«Спросить у Ани» стоит 2,3 млн ₽ в год: считаем цену отсутствия базы знаний в e-com

В понедельник Аня заболела. Аня ведёт ежедневный отчёт по остаткам и рекламе на трёх маркетплейсах и знает, какие артикулы нельзя подтверждать в акциях. До среды отчёт собирали вручную, на третий день ушла в минус карточка с неправильно выставленной ценой. В четверг руководитель написал в общий чат: «Кто-нибудь знает, как Аня это делает?»

Никто не знал. Аня не плохой специалист, наоборот: именно поэтому всё держалось на ней.

Обычно такие истории разбирают как проблему дисциплины: люди не документируют, нужно заставить. Я за последние годы пересобирал процессы и отделы в e-com-командах и вижу другое. Заставить не получается, потому что у базы знаний нет хозяина, а у отсутствия хозяина есть конкретная цена. Давайте её посчитаем и потом разберём, кто и как должен за базу отвечать.

Почему привычные объяснения не работают

Первое объяснение: «У нас нет времени писать документацию». Время есть, просто оно уже тратится, только в другом месте: на повторные вопросы, ручные выгрузки, исправление ошибок. Ниже будут цифры.

Второе: «Заведём Notion, Confluence или вики, и всё заработает». Инструмент решает около 10% задачи. Типичный сценарий такой: первые две недели все пишут с энтузиазмом, через три месяца половина статей устарела, через полгода никто базе не доверяет и снова спрашивает в чате. Недоверие к одной устаревшей инструкции переносится на всю базу.

Третье: «Пусть каждый ведёт свой раздел». Это классическая трагедия общего: если за целое не отвечает никто, оно деградирует. Раздел по возвратам правят, когда сотрудника уже оштрафовали за ошибку, а не когда маркетплейс поменял правила.

Теперь о том, почему для e-com всё это острее, чем для большинства бизнесов. Знание здесь быстро портится: маркетплейсы меняют комиссии, требования к контенту, схемы логистики и правила акций, причём не по вашему графику. А цена ошибки прямая: штраф, блокировка карточки, потерянная позиция в выдаче, неверная цена в акции. Поэтому в нашей отрасли знание нужно считать активом, у которого есть амортизация и которому нужен баланс.

Модель расчёта: три статьи затрат

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

1. Ручной режим: ежедневный налог

Две составляющие, которые легко замерить за одну неделю.

Ручные отчёты. Три человека тратят по 1,5 часа в день на сборку данных из кабинетов маркетплейсов, рекламы и складских таблиц:

3 × 1,5 ч × 22 дня = 99 ч в месяц, или около 79 тыс. ₽.

Повторные вопросы. «Где лежит шаблон карточки?», «Как оформлять возврат с браком?», «Почему этот артикул не в акции?». Если каждый из 12 человек тратит в день по 20 минут, спрашивая или отвечая (отвечающий теряет время вдвое сильнее, но возьмём среднее):

12 × 20 мин × 22 дня = 88 ч, или около 70 тыс. ₽.

Итого около 150 тыс. ₽ в месяц, то есть примерно 1,8 млн ₽ в год. Это постоянный налог, он не требует никаких происшествий.

2. Онбординг: цена каждого найма

Новичок в e-com выходит на самостоятельную работу за 4–8 недель. Возьмём шесть и допустим, что средняя продуктивность за этот период 50%. Тогда недоданная работа составляет три недели:

3 нед × 32 тыс. ₽ (недельная стоимость сотрудника) ≈ 96 тыс. ₽.

Добавим время наставника, час в день при 22 рабочих днях по 800 ₽, но с учётом того, что он не только учит, но и работает: ≈ 18 тыс. ₽. Итого около 115 тыс. ₽ на человека. Если команда меняется на 25% в год, это трое новых людей и около 345 тыс. ₽.

Здесь нужна оговорка. Часть этих затрат неизбежна: любому новичку нужно время. Но в командах без базы знаний процесс «передаётся голосом», и срок растягивается из-за того, что наставник занят и объясняет каждому по-своему.

3. Уход ключевого человека: ожидаемая потеря

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

Допустим, в команде трое «носителей» (как Аня), вероятность ухода каждого за год 20%. Цена одного ухода без учёта онбординга, который уже посчитан выше:

Итого около 210 тыс. ₽ на событие. Ожидаемые потери: 3 × 0,2 × 210 = 126 тыс. ₽ в год.

Но я бы не обольщался усреднением. Это не равномерный расход, а разовый удар в конкретный месяц, и у него есть «хвост»: блокировка аккаунта из-за пропущенного требования стоит больше всего вышеперечисленного. Модель этот хвост не отражает, поэтому оценка консервативна.

Итог

1,8 млн + 0,345 млн + 0,126 млн ≈ 2,3 млн ₽ в год для команды из 12 человек.

База знаний не обнулит эти потери. Я бы закладывал, что она снимает 30–40%: отчёты останутся (их закрывает автоматизация, а не документация), вопросы не исчезнут полностью. Это 0,7–0,9 млн ₽ в год.

Сколько стоит владелец и окупается ли он

Владельцу базы знаний на команду такого размера нужно около 20–25% рабочего времени, это 340–420 тыс. ₽ в год. При эффекте в 0,7–0,9 млн получаем окупаемость примерно в два раза. Это не космос, зато честная цифра.

Если по вашим данным результат выходит ниже (маленькая команда, редкая текучка, процессы простые), отдельная роль вам не нужна. Хватит регламента на полстраницы и назначенного человека. Если выше (20+ сотрудников, много каналов продаж, планируете ИИ-агентов), окупаемость растёт, потому что нагрузка на владельца растёт медленнее, чем команда.

Кто должен отвечать за базу знаний

Начну с тех, кто не подходит.

Подходит человек, который хорошо знает операционку e-com, умеет структурировать и обладает достаточным весом, чтобы потребовать у коллег актуализировать знания. На практике это операционный менеджер или методолог процессов. Название роли не принципиально: «владелец базы знаний», «редактор процессов», «knowledge owner».

Важное разделение. Владелец не пишет всё сам. Он отвечает за систему:

А за содержание каждой статьи отвечает конкретный владелец процесса (категорийный менеджер за карточки, логист за поставки, маркетолог за рекламу). У статьи в шапке стоят имя, дата последней проверки и срок следующей. Это простая схема ответственности: система у одного человека, знания у экспертов.

KPI роли

Худший показатель, который можно выбрать, это «количество статей». Он поощряет бесполезный объём. Мне нравятся такие:

Как держать актуальность: два механизма

Обновление по триггеру. Один человек (можно сам владелец, можно аналитик) отслеживает изменения: новости и рассылки Wildberries, Ozon, Яндекс Маркета, изменения оферт, обновления API. Любое изменение превращается в задачу: найти затронутые статьи → назначить владельца процесса → обновить → поставить дату → оповестить команду. Важно, чтобы задача была формальной (тикет, а не «кто-то увидит»), иначе всё сведётся к случайности.

Ревизия раз в квартал. Каждая статья имеет дату проверки. Просроченные автоматически помечаются, например «Требует проверки», и попадают в список владельцу. Статьи, которые никто не открывал полгода, уходят в архив: пустой шум мешает поиску.

Принцип, который стоит запомнить: устаревшая статья хуже отсутствующей. Отсутствие инструкции заставляет человека спросить. Устаревшая инструкция заставляет сделать неправильно уверенно. Для ИИ-агента это критично: он не сомневается, а выдаёт устаревшее как факт.

Одна база: онбординг и ИИ-агенты

Это самое интересное с точки зрения экономики: один актив работает на двух «читателей».

У новичка и у ИИ-агента похожая проблема, у них нет контекста. Они не знают, «как у нас принято», что значит «сделать как обычно» и кто что имел в виду. Поэтому хорошая статья для них пишется одинаково:

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

Отсюда же консультантский взгляд на автоматизацию: нельзя автоматизировать процесс, который не описан. Сначала вы фиксируете, как он работает, потом решаете, что отдать скрипту или агенту (часто это те самые три человека с ручными отчётами), а что оставить человеку. Описание процесса первично, автоматизация вторична. Без базы знаний автоматизация воспроизводит хаос быстрее.

Диагностика: пять вопросов за пять минут

Задайте их себе или команде:

Если на пятый вопрос ответ «все понемногу», у вас нет владельца, и это первое, что надо исправить.

Как ввести роль в этом месяце

Неделя 1. Назначьте владельца (даже на 20% времени), выберите 20–30 критичных процессов, замерьте текущие затраты за неделю: отчёты и повторные вопросы.

Неделя 2. Утвердите шаблон статьи (цель, шаги, исключения, владелец, дата проверки). Опишите первые 5 самых дорогих процессов: отчёты, обновление карточек, акции, возвраты и штрафы, поставки.

Неделя 3. Запустите процесс обновления: кто мониторит изменения маркетплейсов, как создаётся задача, в какой срок закрывается. Назначьте первую ревизию через 90 дней.

Неделя 4. Проведите онбординг следующего человека «по базе» и замерьте время и количество вопросов. Если есть ИИ-ассистент, подключите его к базе на пилоте и соберите вопросы без ответа.

Через месяц у вас будет не идеальная база, а работающий контур: владелец, шаблон, процесс обновления и цифры, с которыми можно спорить и которые можно улучшать.

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

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