Кейс: Odoo CRM + склад для оптовой компании на 18 человек

Исходная точка — «зоопарк» на 18 человек

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

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

Три системы, которые не разговаривали друг с другом

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

• amoCRM на минимальном тарифе. В ней вели контакты и сделки, но по сути использовали как записную книжку: карточка клиента, пара комментариев, сумма. Ни остатков, ни маржи, ни нормальной аналитики — тариф не позволял, а расширять не хотели из-за цены.
• Остатки склада — в Excel на сетевом диске. Один файл, к которому одновременно тянулись шесть менеджеров, кладовщик и закупщик. Каждое утро начиналось с боёв за блокировку: «Закрой файл, мне надо сохранить!». Версии затирались, кто-то работал в устаревшей копии.
• Счета — в 1С у бухгалтера. Менеджер не имел доступа к 1С. Чтобы выставить счёт, он писал бухгалтеру в чат: «Сделай счёт на такого-то, вот позиции». Бухгалтер, когда освобождался, формировал документ и присылал PDF обратно. В пик это занимало полдня.

Во что это обходилось в деньгах и нервах

Хаос — это не абстракция, он конвертируется во вполне конкретные потери. Вот что я зафиксировал на входе в проект:

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

Третья — отсутствие картины воронки. Сколько сделок в работе, на каком этапе застряли деньги, какой менеджер тянет, а какой буксует — на эти вопросы никто не мог ответить цифрами. Планёрки превращались в пересказ по памяти: «Ну, там вроде клиент думает». Управлять этим было невозможно, оставалось только верить на слово.

Именно с таким набором мы и начали. Задача звучала так: свести продажи, склад и расчёт маржи в одну систему, где менеджер в момент разговора с клиентом видит и остаток, и цену, и историю, а собственник — воронку и деньги на одном экране.

Почему выбрали Odoo Community, а не альтернативы

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

Разберу логику отказа от каждого варианта, потому что она важнее самой таблицы.

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

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

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

Отдельно проговорили с собственником про Community-редакцию: официальный docker-образ odoo:19 — это именно свободная версия под лицензией LGPLv3, без лимита на число пользователей и без обязательной подписки. Для торговой компании, где важны прежде всего CRM и склад, платный Enterprise на старте не давал ничего критичного. Решение созрело само.

Архитектура решения

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

Сервер и стек

Взяли VPS у российского хостера: 4 vCPU, 8 ГБ RAM, 80 ГБ SSD. Для восемнадцати пользователей и каталога в несколько тысяч позиций этого с запасом — Odoo на такой конфигурации работает бодро, а место под рост базы и бэкапы остаётся. Российский хостинг выбрали сознательно: данные клиентов и заказчиков должны лежать в понятной юрисдикции, это снимает вопросы по 152-ФЗ, где компания сама выступает оператором персональных данных.

Развернули всё в Docker через docker compose: контейнер odoo:19 (Community) и рядом postgres:16 как база данных. Перед ними — nginx в роли обратного прокси с бесплатным TLS-сертификатом от Let's Encrypt через certbot. Такая связка даёт чистое разделение: обновить Odoo или PostgreSQL можно, поменяв тег образа, а данные живут в отдельных томах и бэкапятся независимо.

Какие модули включили — и какие сознательно не стали

Отдельно про состав. Соблазн включить всё и сразу велик, но это классическая ошибка внедрения — люди тонут в незнакомом интерфейсе и саботируют систему. Мы поставили ровно то, что закрывает текущую боль:

• CRM — воронка, лиды, сделки, аналитика продаж.
• Sales — коммерческие предложения и заказы.
• Inventory — складской учёт и, главное, резервирование товара под сделку.
• Contacts — единая база контрагентов.

А вот Website и Manufacturing на старте не ставили осознанно. Сайт с формами-лидогенераторами — отличная штука, но у клиента на тот момент не было готовности заниматься ещё и веб-каналом, а лишний неиспользуемый модуль только усложняет интерфейс. Производство (Manufacturing) компании-поставщику не нужно в принципе — она торгует, а не производит. Модульность Odoo тем и хороша: включить недостающее можно в любой момент, когда дозреет потребность, а не тащить лишний вес с первого дня.

Почта и доступ

Завели ящик sales@ на собственном сервере mailcow и настроили так, чтобы входящие письма автоматически попадали в CRM лидами — менеджер видит обращение прямо в системе, а не в разрозненных почтовых клиентах. Это закрыло дыру, через которую раньше терялись заявки: письмо прочитали, забыли ответить — и клиент ушёл к конкуренту.

Доступ к системе организовали через HTTPS из любой точки — и из офиса, и с выезда, менеджеры часто на встречах у заказчиков. Для безопасности включили обязательную двухфакторную аутентификацию (2FA по TOTP) всем без исключения — она в Odoo встроена. Система с коммерческими данными и базой клиентов, открытая наружу, без второго фактора — это приглашение к взлому, тут компромиссов быть не может.

Настройка под процесс

Развернуть Odoo — полдела, даже меньше. Ценность рождается в настройке под реальный процесс продаж компании. Здесь мы провели несколько дней в переговорной, разбирая с РОПом и менеджерами, как на самом деле течёт сделка. Расскажу по частям.

Воронка B2B с тендерным крылом

У промышленного поставщика сделки длинные и часто проходят через тендеры или торг. Стандартная короткая воронка «лид — счёт — оплата» тут не работает. Мы собрали стадии под их реальность:

Стадия «Тендер / Торг» — это и есть «тендерное крыло», которого нет в типовых воронках. Именно на ней у клиента застревала половина сделок, и раньше это было чёрным ящиком. Теперь на канбане видно, сколько денег висит в торге и как долго. Для повторных клиентов, которые заказывают регулярно и без тендеров, завели отдельную короткую воронку — гонять постоянного заказчика через полный цикл квалификации бессмысленно, это только замедляет работу.

Каталог на 4000 позиций

Самая трудоёмкая часть. У клиента было около 4000 номенклатурных позиций, разбросанных по нескольким прайсам поставщиков в Excel с разнобоем в артикулах: один и тот же товар мог называться по-разному в двух файлах. Мы:

• Нормализовали артикулы — привели к единому формату, свели дубли, выявили позиции-близнецы.
• Настроили единицы измерения — штуки, метры, комплекты, — чтобы склад считал корректно.
• Загрузили закупочные цены по каждой позиции. Это ключевой момент: имея закупочную и продажную цену в одной карточке, Odoo считает маржу прямо в сделке, в момент её оформления.

Конвертация сделки: от возможности до резерва на складе

А вот и та самая фича, ради которой всё затевалось. Цепочка в Odoo работает так:

1. Менеджер ведёт сделку (Opportunity) по воронке.
2. Готовый к отправке расчёт превращается в коммерческое предложение (Quotation) одной кнопкой — данные клиента и позиции переезжают автоматически.
3. После согласования КП становится заказом (Sales Order).
4. Заказ автоматически создаёт резерв товара на складе (Inventory) — позиции «замораживаются» под этого клиента.

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

Права доступа

Разграничили видимость по ролям, чтобы каждый видел ровно своё:

• Менеджер видит только свои сделки — чужих клиентов не подсматривает, база не утекает при увольнении.
• РОП видит все сделки всех менеджеров — это его инструмент управления.
• Собственник получил дашборды: воронка, выручка, маржа, источники — сводная картина без копания в отдельных карточках.

Миграция и запуск

Настроенная система пуста — в неё надо перенести живые данные, и это отдельное искусство. Ошибка на этом этапе способна похоронить весь проект: если менеджеры зайдут в новую систему и не найдут там своих клиентов и сделок, они мгновенно вернутся в старое. Переносили по нашей отработанной методике — подробно про сам процесс миграции из amoCRM, Bitrix24 и Excel я разбирал в отдельной статье серии про переезд на Odoo CRM, здесь дам суть применительно к этому кейсу.

Из amoCRM надо было перенести 2800 контактов и 340 открытых сделок. Выгрузили, привели к формату Odoo, сопоставили поля. На этапе дедупликации всплыл показательный факт: 19% контактов оказались дублями — один и тот же клиент заведён по два-три раза разными менеджерами, с разными телефонами и обрывками истории. Это прямое следствие того, что в старой CRM никто не следил за чистотой базы. Свели дубли, объединили историю — и клиент впервые получил достоверную картину, сколько у него на самом деле контрагентов.

Заморозку подготовили заранее: убедились, что вся история в Odoo, что менеджеры знают, где что лежит, что почта sales@ ловит лиды. И в назначенный понедельник старую CRM перевели в режим «только чтение». Первые дни были нервными, но именно жёсткая дата отсечения заставила команду по-настоящему перейти, а не тянуть одной ногой в прошлом.

Сопротивление людей — честный раздел

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

Первые три недели менеджеры саботировали систему. Не открыто — никто не бунтовал вслух. Просто «забывали» занести активность, вели переговоры в личных мессенджерах, держали параллельные заметки в блокноте. Universal-отговорка звучала так: «В амо было привычнее». По-человечески их можно понять: у них есть план продаж, а тут вместо звонков клиентам приходится осваивать новый интерфейс. Новая система в их глазах была не помощником, а лишней обузой, которую навязало руководство.

Что сработало

• Обязательное поле причины проигрыша. Нельзя закрыть сделку как проигранную, не указав почему: дорого, выбрали конкурента, отвалился бюджет. Мелочь, но она заставила менеджеров осмысленно относиться к каждой сделке — а компания впервые получила статистику, почему теряет клиентов.
• Планёрки только по канбану Odoo. Это оказалось решающим. РОП завёл железное правило: на утренней планёрке обсуждаем только то, что видно в системе. Нет сделки в Odoo — значит, сделки не существует. Рассказы «по памяти» перестали приниматься. Через неделю такого режима все внезапно вспомнили, как заносить данные.
• Персональный дашборд с прогнозом бонуса. Мы показали каждому менеджеру его личный экран: сколько он заработает премии при текущей воронке. Вот это зацепило по-настоящему — когда человек видит свои деньги в зависимости от аккуратного ведения сделок, мотивация появляется сама.

Что НЕ сработало

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

Цифры через полгода

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

Разберу главное словами, потому что за цифрами стоят конкретные изменения в работе.

Сорванные отгрузки: с 3–4 до 0–1 в месяц. Оставшиеся единичные случаи — это уже не «продали то, чего нет», а редкие накладки с поставщиками. Корневая причина устранена: менеджер видит реальный остаток и резерв в момент сделки. Для B2B-поставщика это прямое восстановление репутации и рост повторных заказов.

Время на КП: с четырёх часов до получаса. Раньше цепочка «менеджер → чат → бухгалтер → PDF обратно» съедала полдня и создавала очередь у бухгалтера. Теперь менеджер сам собирает КП в Odoo за считанные минуты, с актуальными ценами и остатками. Бухгалтер разгрузился, скорость реакции на запрос клиента выросла в разы — а в тендерах скорость ответа часто и решает.

Win rate: из «неизвестно» в измеримые 24%. Сам по себе процент — не хорош и не плох, важно, что он теперь существует и разложен по источникам. Стало видно, какой канал привлечения даёт качественные заявки, а какой — пустой трафик. Появилась база для управленческих решений вместо интуиции.

Экономика и главный неожиданный эффект

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

Что бы сделали иначе и планы клиента

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

Наша ошибка

Планы клиента

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

• Модуль Purchase для закупок под заказ. Сейчас, когда товара не хватает под сделку, закупщик работает по старинке. Следующий шаг — чтобы дефицит по заказу автоматически формировал заявку поставщику прямо в системе, замыкая цепочку «сделка → склад → закупка».
• Модуль Website с формами. Позже — сайт с формами-лидогенераторами, которые сбрасывают заявки прямо в ту же воронку CRM. Тогда посетитель сайта станет лидом в той же базе, где живёт весь бизнес, без единого коннектора.

И вот главный вывод, ради которого я и написал этот кейс. Odoo оправдывает себя там, где CRM — это первый шаг к единой системе, а не конечная цель. Если компании нужна просто записная книжка для контактов — это стрельба из пушки по воробьям, есть решения проще. Но если вы, как наш клиент, тонете в «зоопарке» из CRM, Excel и 1С и понимаете, что продажи, склад и закупки должны жить в одном месте, — Odoo раскрывается именно на этой задаче. Мы начали с CRM, а через полгода у компании фундамент ERP, который растёт вместе с ней.

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