Что входит в сопровождение Odoo и как считается цена
Сопровождение и техническая поддержка Odoo — это абонентское обслуживание уже работающей системы: реакция на сбои, обновления, мелкие настройки и доработка модулей под изменившийся процесс. Работает по пакету часов в месяц: часы идут и на аварии, и на развитие, поэтому бюджет предсказуем, а очередь «хотелок» не копится до следующего проекта.
В любой пакет входят: приём обращений в одном канале, диагностика и устранение ошибок, настройка прав и справочников, помощь пользователям, контроль резервных копий, наблюдение за обменом с 1С и сайтом, обновления. Отдельным проектом считаются запуск крупного модуля, перевод подразделения на систему и миграция через несколько релизов.
Цена определяется объёмом пакета и временем реакции. Публично студия называет ступени по составу, суммы по ним — «Дежурство» от 25 000 ₽/мес · «Рабочий» от 55 000 ₽/мес · «Проектный» от 95 000 ₽/мес · час сверх пакета от 3 500 ₽. Ставку часа сверх пакета фиксируем в договоре, чтобы перерасход не обсуждался задним числом.
Нужно это компаниям, у которых Odoo уже запущена. Если система только внедряется, поддержка начинается после приёмки, и первый месяц идёт плотнее остальных — люди задают вопросы, которых не было на обучении.
Пакеты поддержки: что входит в каждый
Конкуренты называют либо число часов без состава, либо состав без часов. Мы делим ступени по тому, что компания получает.
Дежурство — минимальный контур для стабильной системы: резервные копии под контролем, обновления по плану, реакция на отказы, мелкие настройки и консультации. Развитие сюда не входит.
Рабочий — для компаний, где система живёт: добавляются отчёты, меняются печатные формы, появляются роли и поля. Часы делятся между поддержкой и небольшими доработками, приоритет согласуется раз в месяц.
Проектный — когда параллельно с эксплуатацией идёт развитие: подключается подразделение, добавляется модуль, перестраивается обмен. Здесь появляются выделенный ответственный и план работ на квартал.
Объём часов, время реакции и правила переноса неизрасходованных часов фиксируются договором: Дежурство — от 8 ч/мес, реакция в рабочий день; Рабочий — от 20 ч/мес, реакция до 4 ч; Проектный — от 40 ч/мес, реакция до 1 ч на аварию. Неизрасходованные часы не сгорают в пределах календарного месяца пакета, перенос на следующий месяц — по согласованию.
Доработка и разработка модулей Odoo
Доработка меняет поведение системы, настройка — её параметры. Граница проста: если задача решается в интерфейсе администратора, это настройка и она идёт из часов пакета; если нужен код — это разработка с отдельной оценкой.
Что обычно дорабатывают: собственные поля и вкладки в документах, отчёты и печатные формы под требования компании, действия по событию, правила ценообразования, ограничения прав тоньше штатных, интеграции с внешними сервисами.
Правило, которое экономит деньги на дистанции: доработка делается отдельным модулем, а не правкой ядра. Изменённое ядро превращает каждое обновление в проект с непредсказуемым сроком, и через два релиза компания заперта на старой версии. Собственный модуль обновление переживает, а ломается в одном известном месте.
Примеры оценок конкретных задач со сроком и ценой — формат, который в нише не перенесён никем: поле/отчёт — от 5 000 ₽ · печатная форма — от 15 000 ₽ · небольшой модуль — от 45 000 ₽.
Обновление Odoo: почему оно ломается и как мы его проводим
Odoo выпускает версию раз в год, и поддержка старых не бесконечна. Компании тянут с обновлением, пока не упрутся: перестал работать модуль, не ставится интеграция, вендор не выпускает исправления безопасности. К этому моменту разрыв уже в три-четыре релиза, и обновление становится проектом вместо регламентной работы.
Ломается оно по трём причинам: правки в ядре, о которых никто не помнит; сторонние модули без версии под новый релиз; данные, не прошедшие проверки новой версии. Ни одну нельзя увидеть, обновляя боевую базу сразу.
Поэтому порядок такой: копия боевой базы на отдельном сервере, пробное обновление на ней, список сломавшегося, правка собственных модулей, повторный прогон, проверка заказчиком на тестовом контуре и только потом переключение — в окно, согласованное заранее, с готовым планом отката. Обмен с 1С и сайтом проверяется отдельным пунктом: он ломается при обновлениях чаще самой системы.
Как устроена работа: каналы, приоритеты, отчётность
Обращения идут в один канал и попадают в трекер, а не в переписку с конкретным разработчиком: заявка в мессенджере исчезает вместе с его отпуском. У задачи есть автор, приоритет, ответственный и срок.
Приоритеты разделены по последствиям: остановка работы подразделения — первый, ошибка с обходным путём — второй, улучшение — плановая очередь. Это важнее средней скорости: упавший склад не встанет в очередь за цветом кнопки.
Раз в месяц заказчик получает отчёт: что закрыто, сколько часов потрачено и на что, что осталось в очереди и что мы предлагаем взять дальше. Время реакции по приоритетам и график работы службы — P1 (остановка подразделения): реакция до 1 ч в окне пакета; P2 (есть обходной путь): до 4 ч в рабочий день; плановые улучшения — в очереди месяца. Базовый график — рабочие дни 10:00–19:00 МСК; дежурство вне часов — в пакете «Проектный» или отдельным соглашением.
Один договор на систему и на сервер под ней
Odoo — не веб-сервис, а приложение на сервере: база данных, фоновые задания, очереди обмена, резервные копии и место на диске, которое однажды заканчивается. Половина обращений в поддержку ERP относится к инфраструктуре: система «тормозит» из-за нехватки памяти, обмен встал из-за упавшего процесса, отчёт не строится, потому что база не обслуживалась год.
Когда система и сервер разведены по подрядчикам, каждое такое обращение начинается с выяснения, чья это зона. Мы держим оба звена по одному договору, с общим мониторингом: обновление Odoo и обновление операционной системы планируются в одном окне, а не в двух, назначенных двумя командами.
Третье звено — обмен с 1С и сайтом. Он живёт на стыке и в чужой зоне ответственности оказывается ничьим. У нас он входит в мониторинг: журнал проверяется автоматически, и о вставшей очереди мы узнаём раньше, чем менеджер заметит, что заказы перестали приходить.