Коротко: Команда, которая обещает «сделаем все, что скажете», поначалу кажется удобной, но каждое пожелание превращается в кастомный код, обновления ломаются, а расходы растут год от года. Хорошее техническое задание на внедрение Odoo описывает не список пожеланий, а бизнес-цели, и для каждого требования сначала проверяет стандартное решение. Deep Vision начинает проекты именно так: диагностика, стандарт, затем только обоснованный код.
Выбирая партнера Odoo, многие руководители ищут самую гибкую команду: «мы подстроимся под ваши процессы, сделаем все как вы привыкли». Обещание приятное, ведь никто не хочет менять привычки. Но если техническое задание Odoo составлено неправильно, такая гибкость становится самой дорогой ошибкой проекта. Разберем, почему подход «чего изволите» опасен, как его распознать и что требовать взамен.
Что такое подход «сделаем все, что скажете»?
Подход «сделаем все, что скажете» — это стиль работы подрядчика, при котором каждое требование заказчика принимается без анализа и сразу превращается в настройку или код. Такая команда не задает вопросов, не спорит и не говорит «это есть в стандарте» или «это не нужно». Она работает как приемщик заказов.
Внешне это выглядит как уважение к клиенту. На деле никто не задает главных вопросов: какую проблему решает требование, можно ли закрыть его готовой функцией Odoo, кто будет поддерживать этот код через два года?
Почему техническое задание Odoo не должно быть списком пожеланий?
Во многих компаниях ТЗ появляется так: каждый руководитель отдела пишет свои пожелания, их сводят в один файл и отправляют подрядчику. В документе оказывается 150 пунктов, и многие из них копируют экраны старой программы и таблицы Excel.
Такой список скрывает три проблемы:
- Требования противоречат друг другу (продажи хотят свободно давать скидки, финансы требуют жесткого контроля).
- Многие пункты описывают не процесс, а внешний вид экрана.
- Ни один пункт не привязан к бизнес-результату: колонки «зачем это нужно» нет.
Хорошее ТЗ устроено иначе. Сначала цели (например, «сократить время сборки заказа», «видеть дебиторку ежедневно»), затем процессы и только в конце экраны и отчеты. У каждого требования стоит отметка: стандарт, настройка или кастомный код.
Что происходит, когда каждое пожелание превращается в код?
Последствия подхода «приемщика заказов» обычно проявляются не в первый год, а на второй и третий:
- Ломаются обновления. Odoo ежегодно выпускает новую версию. Каждый кастомный модуль нужно переносить и заново тестировать. Чем больше модулей, тем дороже и рискованнее обновление.
- Растут расходы. Код пишется один раз, а поддерживать его приходится каждый год.
- Автоматизируется хаос. Если процесс неправильный, точное копирование его в систему лишь ускоряет ошибки.
- Возникает зависимость от подрядчика. Систему с большим количеством нестандартного кода трудно передать другой команде.
По исследованию McKinsey и Оксфордского университета, охватившему более 5 400 IT-проектов, крупные проекты в среднем выходят за бюджет на 45% и приносят на 56% меньше ценности, чем ожидалось; каждый дополнительный год длительности увеличивает перерасход на 15% (McKinsey). Неуправляемые требования ведут проект именно по этому пути.
Что говорят цифры Gartner?
По прогнозу Gartner, более 70% недавно внедренных ERP-инициатив к 2027 году не достигнут в полной мере исходных бизнес-целей (Gartner). По словам аналитика Gartner, которого цитирует The Register, 70% проектов не выполняют цели бизнес-обоснования полностью, а 25% заканчиваются катастрофическим провалом (The Register).
Эти цифры говорят не о плохих технологиях, а об управлении проектом. ERP-проект — это не установка программы, а изменение бизнес-процессов. Если партнер не предлагает менять процесс, а лишь переносит старый на новые экраны, результат останется прежним.
Поэтому при оценке подрядчика важно не то, сколько функций он пообещал, а сколько лишней работы помог избежать. Если уже на первой встрече команда задает вопросы о процессах, указывает на противоречивые требования и предлагает альтернативы, это хороший признак. Мгновенное согласие на все подряд, наоборот, повод насторожиться.
Как выглядит хороший совет?
Квалифицированный партнер Odoo иногда говорит «нет» и объясняет почему. Например:
- «Этот отчет не нужно писать отдельно: в стандартном сводном отчете Odoo с группировкой вы получите те же данные».
- «Трехступенчатое согласование на складе можно сделать кодом, но его закрывают стандартные маршруты и права доступа, и при обновлении проблем не будет».
- «Это требование действительно ваше конкурентное преимущество, поэтому сделаем его отдельным модулем и задокументируем».
Обратите внимание: хороший консультант не против всего подряд. Он не отказывается писать код, а превращает его в осознанное решение. О выборе между готовой системой и разработкой с нуля: ERP с нуля или готовая система.
Как проверить подрядчика: чек-лист для заказчика
После коммерческого предложения и первых встреч ответьте на вопросы:
- Сказал ли подрядчик хотя бы об одном вашем требовании «это есть в стандарте, код не нужен»?
- Выделен ли в предложении отдельный этап анализа или диагностики?
- Отмечено ли в ТЗ для каждого требования «стандарт / настройка / код»?
- Указаны ли объем кастомного кода и стоимость его обновления?
- Предложил ли подрядчик изменить процесс или только пообещал перенести старый?
- Согласован ли порядок оформления запросов на изменения (change request)?
- Есть ли подрядчик в каталоге партнеров на odoo.com и указаны ли там клиентские референсы?
Если на первые два вопроса ответ «нет», возможно, вы говорите с командой-приемщиком заказов. Полный список вопросов: Как выбрать партнера Odoo в Узбекистане.
Как Deep Vision работает с техническим заданием?
Deep Vision — официальный Odoo Gold Partner из Ташкента. На нашей странице на odoo.com указаны 7 сертифицированных специалистов, более 20 клиентских референсов и удержание клиентов 89% (страница партнера). Остаются ли клиенты с партнером, обычно зависит от того, как система работает в годы после запуска.
Наш порядок работы:
- Диагностика: интервью с руководителем и отделами, фиксация целей.
- Карта требований: каждое требование помечается как стандарт, настройка или код и согласуется с заказчиком.
- Готовые решения: для Didox и «Асл белгиси» у нас есть готовые модули, поэтому эти интеграции не пишутся каждый раз с нуля.
- Поэтапный запуск: стандартные Продажи и Склад часто запускаются за 6–8 недель, полный проект обычно занимает 2–6 месяцев.
В команде есть опытные специалисты, которые знают отрасли и финансы, поэтому наше «нет» всегда аргументировано. О структуре цены: Стоимость Odoo ERP в Узбекистане. Об услуге: внедрение Odoo.
Хотите, чтобы мы посмотрели ваше ТЗ, — заполните бриф.
Частые вопросы
У нас уникальные процессы, стандартного Odoo не хватит?
Некоторые процессы действительно уникальны. Но на практике большая часть требований закрывается стандартными модулями и настройкой. Писать код имеет смысл только для оставшейся части.
Должны ли мы писать ТЗ сами?
Вы формулируете цели и проблемы, а документ стоит составлять вместе с консультантом партнера. Готовый список не заменяет этап анализа.
Если подрядчик говорит «нет», значит, он не хочет работать?
Если «нет» сопровождается альтернативным решением, это профессиональный совет. Необоснованный отказ — другое дело.
Чем больше кастомного кода, тем хуже?
Дело не в объеме, а в обоснованности. У каждого модуля должны быть причина, документация и план обновления.
Что делать, если новое требование появилось в ходе проекта?
Это нормально. Важно оформить его как запрос на изменение и оценить влияние на стоимость и сроки.
Источники
- Deep Vision, страница партнера на odoo.com
- Gartner: ERP-инициативы и ожидаемые результаты
- The Register: аналитик Gartner о провалах ERP
- McKinsey: как завершать крупные IT-проекты в срок и в бюджет
Начните ТЗ с целей, а не с пожеланий: заполните бриф или позвоните: +998 77 093 00 07.