Кейс: переводим оптовую торговую компанию на Odoo Community — от Excel-хаоса до управляемого склада за 6 недель

Портрет клиента: опт плюс мелкая сборка, 25 рабочих мест и остатки, которым никто не верит

Меня зовут Евгений Семёнов, я технический директор компании ITfresh. Мы больше пятнадцати лет обслуживаем IT-инфраструктуру юридических лиц в Москве — как правило, это организации до 50 рабочих мест, — и держим собственное серверное оборудование в дата-центре МТС. Перед вами финальный материал серии «Odoo Community как ERP»: после обзора платформы, инструкции по установке, разбора локализации и регламента эксплуатации логично показать, как всё это складывается в живой проект. Кейс композитный: я собрал его из нескольких наших внедрений с похожим профилем, изменив детали, которые могли бы указать на конкретного заказчика. Сроки, трудозатраты и набранные шишки — из практики, без ретуши.

Итак, дано. Дистрибьютор электротехнической продукции: кабель, автоматика, крепёж, монтажная фурнитура. Особенность, которая сразу отличает его от «чистого» оптовика, — небольшой сборочный участок: из закупных позиций компания комплектует готовые монтажные наборы под типовые объекты и продаёт их как отдельный товар с собственным артикулом. Штат — 25 рабочих мест: четыре менеджера продаж, руководитель отдела, закупщик, два кладовщика, двое сборщиков, бухгалтерия на 1С и административный персонал. Склад — около 1200 активных SKU, из них примерно 180 позиций дают основную оборачиваемость.

Симптомы на момент обращения:

• Остатки жили в Excel и расходились с реальностью на 10–15%. Контрольные пересчёты по ходовым позициям стабильно находили разницу, а полной инвентаризации не делали больше года — «некогда».
• Заявки клиентов жили в личных мессенджерах менеджеров. Когда один из них ушёл в отпуск, две заявки на приличные суммы просто никто не увидел. Клиенты ушли к конкуренту — это и стало последней каплей для директора.
• Закупки велись «по ощущениям». Закупщик заказывал то, что, по его памяти, заканчивалось. В итоге ходовой кабель периодически пропадал со склада на неделю, а редкие позиции лежали мёртвым грузом по полтора года.
• Сборка наборов нигде не учитывалась. Комплект собрали — компоненты со склада исчезли, но в таблице этого никто не отразил. Отсюда и приличная доля тех самых расхождений.

Почему Odoo Community, а не облачный сервис по подписке? Аргументов было три. Во-первых, арифметика: на 25 сотрудников любой SaaS с тарификацией «за пользователя» превращается в заметный ежегодный платёж, а Community-редакция под лицензией LGPLv3 не ограничивает число пользователей вовсе — платить нужно только за виртуальный сервер. Во-вторых, функциональный охват: компании требовались одновременно CRM, продажи, закупки, склад с партионным учётом и производственный контур для сборки наборов — в бесплатной редакции Odoo все пять модулей есть из коробки, что мы подробно разбирали в первой статье серии. В-третьих, данные: директор прямо сформулировал, что база клиентов и цены должны лежать на сервере компании, а не в чужом облаке.

Неделя 0 — обследование и правила игры

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

Первое — карта процессов на одном листе. Мы прошли путь товара и денег руками: как заявка попадает к менеджеру, кто и где проверяет остаток, как резервируется товар (спойлер: никак — «я крикнул кладовщику»), кто решает, что пора закупать, как собирается комплект. Получилась схема «заявка → резерв → комплектация → отгрузка» с ответвлением «точка заказа → закупка», и на ней сразу проявились дыры: резерва не существует как явления, а сборка вообще не оставляет следов в учёте.

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

Третье — граница с бухгалтерией. С главбухом договорились на берегу: Odoo — оперативный контур (сделки, склад, закупки, сборка), 1С — регламентированный учёт и отчётность. Никакого «переведём бухгалтерию на Odoo» в проекте нет — почему мы всегда проводим границу именно так, я объяснял в статье про локализацию Odoo в России. Бухгалтерия при таком раскладе перестаёт быть противником проекта: у неё ничего не отнимают.

Недели 1–2 — фундамент: сервер, модули, структура склада и импорт данных

Техническая часть — самая предсказуемая. Развернули Odoo 19 Community в Docker на VPS с 4 vCPU и 8 ГБ памяти, с PostgreSQL, обратным прокси и ежедневными бэкапами по расписанию — ровно по схеме из нашей инструкции по установке Odoo 19 на сервер, повторяться не буду. Активировали пять приложений: CRM, Продажи, Закупки, Склад и Производство. Подчеркну для скептиков: все пять входят в бесплатную Community-редакцию, включая производственный модуль со спецификациями и производственными заказами, — за них не платят ни рубля лицензий.

Дальше — структура склада, и вот здесь проектные решения важнее кнопок:

• Локации. Внутри физического склада завели зоны: основное хранение (со стеллажной адресацией по рядам), зона комплектации заказов, зона отгрузки и карантин для брака и возвратов. Не переусердствуйте: адресация до ячейки на складе в 1200 SKU — избыточна, мы остановились на уровне стеллажа.
• Партии. Для кабельной продукции, где клиенты запрашивают сертификаты соответствия на конкретную партию, включили партионный учёт (в Odoo это lots): приёмка требует номер партии, к партии прикрепляется скан сертификата, при отгрузке номер уходит в документы. Для метизов и фурнитуры партии не включали — учёт ради учёта никому не нужен.
• Стратегия резервирования и списания. Резерв — автоматически при подтверждении заказа, списание партий — по FIFO, чтобы старые партии уходили первыми и сертификаты не «протухали» на складе.

Теперь честно про импорт — то, о чём в маркетинговых кейсах пишут одной строкой «перенесли данные». Импорт 1200 SKU занял четыре итерации. Первая упала на единицах измерения: кабель у клиента учитывался то в метрах, то в бухтах — в разных строках по-разному. Вторая вскрыла расхождения закупочных цен с прайсами поставщиков. Третья — задвоенные артикулы у товаров-аналогов. Четвёртая легла в базу. Контрагентов было около 800; там ушло три прохода: дубли по ИНН, «ООО Ромашка» и «Ромашка ООО» как две разные компании, контакты менеджеров, приклеенные к чужим организациям. Планируйте на выверку импорта полную рабочую неделю специалиста со стороны клиента — меньше не бывает, сколько бы ни обещали обратное.

Недели 3–4 — процессы: CRM, товарный поток, перезаказ и сборка комплектов

К третьей неделе система наполнена данными, и начинается главное — настройка процессов под то, как компания реально работает. Четыре блока.

Воронка CRM под реальный цикл сделки

Мы не стали брать стандартные стадии из коробки. Разговор с менеджерами показал реальный цикл: «Новая заявка → Уточнение спецификации → КП отправлено → Счёт выставлен → Предоплата получена». Всё, что менеджер раньше держал в голове и мессенджере, теперь живёт в карточке сделки: спецификация, переписка, договорённости о скидке. Заявки с почты компании падают в воронку автоматически — адрес отдела продаж подключили к CRM, и письмо само становится лидом. Сделали три шаблона коммерческих предложений с автоподстановкой позиций из каталога: время подготовки типового КП упало с сорока минут до семи.

Цепочка «заказ → резерв → комплектация → отгрузка»

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

Правила перезаказа вместо закупок «по ощущениям»

По 180 ходовым позициям завели правила перезаказа: минимальный и максимальный уровень запаса. Точку заказа посчитали грубо — средний недельный расход, умноженный на срок поставки с запасом. Как только свободный остаток проваливается ниже минимума, Odoo сама формирует черновик заказа поставщику на пополнение до максимума. Закупщик утром открывает список черновиков, правит количества по своему опыту и отправляет. Важно: мы не отобрали у человека решение — мы отобрали у него необходимость держать 180 позиций в памяти. Через месяц он сам попросил расширить правила ещё на полсотни позиций.

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

Для монтажных наборов завели спецификации (BoM): состав компонентов на один комплект. В Odoo есть два способа работать с наборами: «kit», когда комплект разбирается на компоненты в момент отгрузки, и полноценный производственный заказ, когда компоненты списываются, а на склад приходуется готовое изделие. Мы выбрали второй путь, потому что у клиента наборы собирают заранее на склад, а не под конкретную отгрузку. Теперь сборщик запускает производственный заказ, система списывает компоненты с остатков и приходует готовые комплекты — та самая дыра, через которую утекала заметная часть расхождений, закрылась полностью. Бонусом появилась честная себестоимость набора: сумма компонентов видна в момент сборки, и обнаружилось, что один из ходовых комплектов продавался с маржой втрое ниже, чем думал директор.

Недели 5–6 — люди и запуск: обучение по ролям, параллельный учёт и бунт кладовщика

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

Обучение делали по ролям, а не «всех по всему». Вместо одного толстого мануала — три короткие инструкции по две-три страницы: менеджеру (сделка, резерв, КП, счёт), кладовщику (приёмка с партиями, комплектация, отгрузка, пересчёт), закупщику (черновики перезаказа, приёмка, цены). Каждую роль учили отдельно, по часу-полтора, на их собственных вчерашних заказах, а не на абстрактных примерах. Человек, увидевший в учебной системе своего реального клиента, включается на порядок быстрее.

Две недели параллельного учёта. Старый Excel не выключали: команда вела операции в обеих системах, а мы каждый вечер сверяли расхождения. Да, это двойная работа и все ворчат. Но именно параллельный период выловил десяток ошибок настройки — от неправильной единицы измерения у бухты кабеля до забытой локации карантина. На стыке провели полную инвентаризацию — она и дала точную стартовую цифру: реальное расхождение книжных остатков с фактом составило 12%.

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

Интеграция с бухгалтерией: еженедельная выгрузка в 1С и что мы осознанно не автоматизировали

Схема обмена с 1С намеренно простая. Раз в неделю, по понедельникам, из Odoo выгружается реестр реализаций за прошедшую неделю — табличный файл с контрагентами, суммами и позициями. Бухгалтер загружает его в 1С типовой обработкой и там же формирует счета-фактуры и закрывающие документы. Сверка встроена в тот же ритуал: бухгалтер сличает итоги реестра с банковскими поступлениями и раз в месяц — с складскими остатками по выборочным позициям. На всю процедуру уходит около часа в неделю. Подробно про разделение контуров и варианты обмена — в статье о локализации Odoo и работе рядом с 1С.

Что мы осознанно не стали автоматизировать на старте — и почему:

• Онлайн-обмен Odoo ↔ 1С в реальном времени. Разработка и отладка коннектора стоила бы дороже, чем год ручных еженедельных выгрузок, а цена ошибки в автоматическом обмене — рассинхронизированные базы, которые потом сводят неделями.
• Автоматическую отправку документов клиентам через ЭДО из Odoo. Документооборот остался в контуре 1С, где он и так налажен.
• Синхронизацию платежей из банка в Odoo. Статус «предоплата получена» менеджеру раз в день проставляет бухгалтер по банковской выписке — этого достаточно.

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

Результаты через три месяца: цифры и то, что не получилось

Через три месяца промышленной эксплуатации сняли контрольные показатели и сравнили со стартовой точкой:

• Точность остатков: расхождение упало с 12% до менее 2%. Помимо самой системы, сработали цикловые инвентаризации: вместо одной большой ревизии раз в год кладовщики пересчитывают по 15–20 позиций в неделю по графику, начиная с самых оборачиваемых. Пересчёт встроен в рутину и не останавливает склад.
• Срок от заявки до отгрузки сократился примерно на 40% — с трёх-четырёх рабочих дней до полутора-двух. Основной выигрыш дали моментальный резерв (менеджер подтверждает наличие в момент разговора) и задания на комплектацию вместо устных просьб.
• Потерянных заявок — ноль. Всё, что пришло на почту отдела продаж, автоматически стало лидом в CRM; отпуск или увольнение менеджера больше не означает потерю его «личной» клиентской переписки.
• Закупки перешли от интуиции к точке заказа. Дефицит ходовых позиций за квартал случился дважды (раньше — почти еженедельно), и оба раза по вине срыва сроков поставщиком, а не из-за «забыли заказать». Свободные деньги перестали замораживаться в страховых закупках «на всякий случай».
• Себестоимость комплектов стала видимой. По двум наборам пересмотрели цены, по одному — состав; сборочный участок впервые перестал быть «чёрным ящиком».

Теперь о том, что пошло не по плану, — без этого кейс был бы рекламной листовкой. Отчёты для директора мы переделывали дважды. Первая версия — стандартные представления Odoo: канбан воронки, сводка по складу. Директору не зашло: «мне нужна одна страница с цифрами недели, а не десять экранов». Вторая итерация — настроенные сводные таблицы по продажам и оборачиваемости — оказалась ближе, но окончательно прижился только третий вариант: короткая еженедельная выгрузка из пяти показателей, которую он читает с телефона. Вывод, который мы теперь закладываем в каждый проект: управленческую отчётность нельзя «сдать» — её можно только подогнать по руке за две-три итерации, и это нормально. Ещё из честного: двое из четырёх менеджеров первые недели вели «теневые» заметки параллельно с CRM, и отучили их не запреты, а момент, когда CRM впервые спасла сделку заболевшего коллеги.

Шаблон для повторения: план-график, бюджет и топ-5 ошибок

Этот план мы применяем с минимальными вариациями на компаниях от 15 до 50 рабочих мест. Берите как каркас — календарь и трудозатраты реалистичны при условии, что справочники чистит сторона клиента, а настройку ведёт подрядчик с опытом Odoo.

Бюджет проекта в часах и деньгах — усреднённый по нашим внедрениям этого масштаба:

И топ-5 ошибок внедрения ERP в малом бизнесе — те, что мы разгребаем за другими чаще всего. Каждую закрывает свой этап этой серии статей:

1. Импорт грязных справочников «потом почистим» — не почистите; чистка до старта — половина успеха (этот кейс, неделя 0).
2. Выбор системы по демо-ролику, а не по границам редакций — какие модули реально бесплатны, разбирает обзор Odoo Community 19.
3. Сервер «как-нибудь», без бэкапов и обновлений — закрывается инструкцией по установке и регламентом эксплуатации Odoo.
4. Попытка затащить в ERP регламентированный учёт вместо 1С — где проходит граница, объясняет статья о локализации.
5. Запуск без параллельного периода и обучения по ролям — «мы разослали мануал» не работает никогда (этот кейс, недели 5–6).

Если вы узнали в портрете клиента свою компанию — приходите, пройдём этот путь вместе: мы в ITfresh берём проект целиком, от обследования и сервера до обучения кладовщиков и регламента сопровождения. Написать проще всего в Telegram @ITfresh_Boss или позвонить по номеру +7 903 729-62-41 — за один разговор оценим, ляжет ли ваш процесс на Odoo Community и во что обойдётся внедрение.