CRM и складская система: как связать задачи с товарами

Между складской системой и CRM всегда есть слой работы, который не принадлежит ни одной из них: правки карточек, разбор инцидентов, согласование изменений. Обычно он живёт в переписке.

Что именно теряется между двумя системами

Не данные, а работа. Остатки и движения ведёт складская программа, клиентов и продажи — CRM, и обе делают это хорошо.

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

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

Как устроена привязка задач к товарам

Ключевая идея простая: задача заводится не «про склад вообще», а про конкретную позицию на конкретном складе.

Контур в проекте состоит из пяти шагов: привязка задачи к позиции и складу, обновление листинга, дизайн-правки карточки, проверка продаж, синхронизация статусов. Два источника — задачи из складской программы и инциденты по товарам.

Что это даёт на практике. Исполнитель открывает задачу и сразу видит товар со всей историей: что меняли, кто, когда и с каким результатом. Вопрос «о чём речь» исчезает целиком, а не сокращается.

Второй эффект — накопление. Через несколько месяцев по каждой позиции видно, сколько раз с ней возникали проблемы. Это меняет разговор с поставщиком и с производством, потому что вместо ощущения появляется список.

Почему обмен здесь двусторонний

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

Складская система меняет статусы, остатки и движение — это её данные. CRM меняет описания, условия продажи и результаты разбора инцидентов — это её. Обе стороны действительно ведут работу, а не только читают, поэтому обмен идёт в обе стороны.

Цена такого решения — договорённость по каждому полю о том, чья версия побеждает при одновременном изменении. Обсуждать это нужно с людьми из обеих систем, и на это уходит больше времени, чем на саму настройку. Общий разбор темы — интеграция Битрикс24 с 1С, там же перечислены места, где обмен ломается.

Что дал проект в числах

Ручных ошибок в учёте стало на 40% меньше. Правки карточек товаров стали проходить вдвое быстрее. Подготовка отчётов ускорилась на 30%.

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

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

Кому это подходит

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

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

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

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

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

Сопутствующий вопрос про отчётность на стыке разобран отдельно: отчёты Битрикс24 или внешний BI. Другие связки между системами — на странице интеграций.