Проблема
Компания росла без единого плана автоматизации: каждый отдел заводил свой инструмент под свою задачу. К началу проекта работа держалась на шести несвязанных сервисах.
- Сайт на отдельной платформе — каталог и заявки жили сами по себе, менеджер переносил заказы руками.
- Облако Nextcloud — договоры, сканы и техническая документация лежали в папках, к которым у разных сотрудников разный доступ.
- 1С — учёт: счета, реализация, склад, бухгалтерия.
- Почтовые клиенты — переписка с клиентами и поставщиками вне всякой системы.
- Мессенджеры — согласования, заявки с объектов, фото и правки «в личке».
- Офисные документы — сметы, спецификации и расчёты в файлах на компьютерах.
Дальше начинаются предсказуемые следствия. Одни и те же данные живут в нескольких местах и расходятся: контрагент правится в 1С, но остаётся старым в файле договора и в переписке. Непонятно, где актуальная версия документа — у каждого своя копия. Заявка, согласованная в мессенджере, не попадает в учёт, и её приходится вводить заново. Файл в облаке живёт по ссылке: доступ есть у того, кому её передали, и ни у кого больше. Руководитель не может собрать картину по компании без ручной сводки от нескольких человек, а к моменту, когда сводка собрана, часть решений уже потеряла актуальность.
Решение
Задачу сформулировали так: заказы, документы, учёт, файлы и согласования — в одной системе, с общей базой данных и едиными правами доступа, без переписки «пришли актуальный файл» и без двойного ввода. Каждый слой прежнего набора закрывали своей частью Odoo.
1. Учёт и справочники
Перенесли справочники, номенклатуру, контрагентов и остатки. Продажи, склад и закупки настраивали под фактическую работу компании, а не «как в инструкции к типовой конфигурации»: с теми статусами, согласованиями и печатными формами, которые уже использовались в работе. Это тот слой, от которого зависит всё остальное — пока справочники не сведены, автоматизировать нечего.
2. Сайт и заявки
Сайт перевели на штатный модуль Odoo: каталог, формы заявок и заказы попадают в систему сразу при заполнении, а не переносятся менеджером в конце дня. Заявка с сайта становится объектом системы со статусом и ответственным, а не строкой в чужой таблице, и по ней видно всю дальнейшую историю.
3. Документы и файлы
Вместо отдельного облака — модуль документов внутри Odoo: папки и теги, поиск по содержимому и реквизитам, публичные ссылки для обмена с контрагентами. Документ привязан к контрагенту, сделке или заказу, поэтому его не нужно искать по папкам и он не остаётся «на диске у одного сотрудника». Права на файл наследуются от прав на объект, с которым он связан.
4. Коммуникации и телефония
Внутренние обсуждения и согласования перенесли в чат Odoo с привязкой к конкретной сделке или документу: решение остаётся в контексте, а не тонет в переписке, и к нему можно вернуться через год. Для звонков развернули интеграцию OCA VoIP поверх Asterisk — звонок из карточки клиента, история и запись разговора рядом со сделкой.
5. Обмен с внешним миром
Электронный документооборот, ККТ и интеграции с маркетплейсами подключали так, чтобы данные попадали в учёт автоматически. Ручной перенос номенклатуры, цен и статусов подписания между сервисами убрали.
6. Российская локализация
План счетов РФ, налоги, печатные формы (УПД, ТОРГ-12, счета-фактуры), регламентированная отчётность — на собственном модуле локализации. Это позволяет закрывать период и сдавать отчётность без параллельной учётной системы.
Результат
- Одна база данных вместо шести сервисов: справочники и документы не расходятся между системами.
- Заявка с сайта сразу становится заказом со статусом и ответственным.
- Документы и история согласований остаются внутри системы: видно, кто, когда и что согласовал.
- Меньше ручного переноса — сотрудники занимаются работой, а не копированием между окнами.
- Права доступа по ролям вместо «файл в общей папке, у кого надо доступ — тот знает ссылку».
- Отчётность и закрытие периода идут из той же системы, где ведётся операционная работа.
Что остаётся вне Odoo
Учётную систему не делают единственным инструментом в компании любой ценой. За контуром обычно остаётся то, что там и должно оставаться:
- узкоспециальное отраслевое ПО — проектирование, CAD, инженерные и расчётные пакеты: они не заменяются ERP и не должны;
- бухгалтерия в 1С — там, где это требование или сложившаяся практика конкретного бухгалтера; обмен между 1С и Odoo настраивается двусторонним, с автоматической сверкой, а не выгрузкой вручную;
- внешние мессенджеры — для переписки с клиентами, которые не готовы уходить в другой канал; внутренние согласования при этом уже в Odoo.
Смысл консолидации — не в том, чтобы «всё было в Odoo», а в том, чтобы у бизнеса была одна точка правды по заказам, документам и деньгам. Сколько сервисов удастся закрыть и в каком порядке — зависит от контура: где-то хватает учёта, сайта и документов, где-то нужны телефония, ЭДО и маркетплейсы.
С чего начать
Если у вас накопился похожий набор — сайт на одной платформе, файлы в облаке, учёт в 1С, переписка в мессенджерах — начинать стоит не с покупки модулей, а с разбора текущих систем: что связано между собой, где данные дублируются, какой участок даёт больше всего ручной работы. Такой разбор делается до проекта и занимает немного времени, зато сразу показывает, что переносится в единый контур, а что дешевле оставить как есть.
Свяжитесь с нами: +7 913 916-61-17, info@erpha.ru