Доработка BAS — один из самых частых запросов к SATELION, и одновременно один из самых рискованных с точки зрения бюджета: клиенты регулярно приходят с проектами, которые подорожали вдвое против первоначальной сметы. По опыту SATELION в десятках доработок, причина почти всегда одна и та же — не сложность самой задачи, а семь типичных ошибок на этапе постановки и ведения проекта. Ниже — что именно обычно ломает бюджет и как этого избежать.
Ошибка 1: размытое техническое задание
Самая дорогая ошибка — начать доработку без чёткого описания результата. Формулировки вроде «сделайте отчёт удобнее» или «добавьте автоматизацию в закупки» оставляют простор для толкования, и исполнитель с клиентом могут представлять совершенно разный результат.
Когда ТЗ нечёткое, доработка неизбежно проходит через несколько итераций переделки — а каждая итерация это дополнительные оплаченные часы. По практике SATELION, чёткое ТЗ с конкретными примерами входных и выходных данных сокращает количество итераций в разы.
Ошибка 2: клиент ведёт проект без PM-контроля
Когда клиент общается напрямую с разработчиком без проектного менеджера, который следит за объёмом задачи, происходит незаметное разрастание скоупа: «а ещё добавьте», «а можно ещё вот это» — и каждое такое дополнение без фиксации в задаче и отдельной оценки часов незаметно удваивает смету.
PM-модель SATELION решает это не запретом прямого контакта с разработчиком, а контролем: клиент так же общается с исполнителем напрямую, но каждое изменение объёма фиксируется и оценивается отдельно, прежде чем попасть в работу.
Ошибка 3: доработка "поверх" вместо интеграции в стандартную конфигурацию
Быстрый, но опасный подход — писать код, который обходит стандартную логику BAS вместо того, чтобы интегрироваться в неё. Это даёт результат быстрее на старте, но после следующего обновления платформы доработка ломается, потому что цепляется за внутреннюю структуру, которую разработчики BAS могли изменить.
Исправление сломанной после обновления доработки стоит почти столько же, сколько стоила сама доработка — фактически клиент платит за работу дважды. Корректный подход — расширять конфигурацию через штатные механизмы расширения, даже если это занимает больше времени на старте.
Ошибка 4: тестирование прямо на боевой базе
Доработка, проверенная сразу на рабочей базе данных, — риск остановки работы всей компании, если что-то пойдёт не так. Но есть и чисто бюджетное следствие: ошибки, найденные после того, как доработка уже попала в работу бухгалтерии или склада, исправляются в срочном режиме — а срочные исправления всегда дороже запланированной работы.
SATELION тестирует каждую доработку на копии базы перед внедрением в боевую систему — это стандартный, а не дополнительно оплачиваемый этап процесса.
Ошибка 5: отсутствие документации изменений
Доработка без документации работает нормально, пока её не нужно менять — новому исполнителю (или даже тому же самому через год) приходится разбирать код заново, чтобы понять логику. Это прямое дополнительное время, которое клиент оплачивает за работу, которая уже была однажды сделана.
Минимальная документация — описание логики изменения и места в конфигурации, где оно сделано — стоит несколько часов на этапе разработки и экономит в разы больше при любом последующем изменении.
Ошибка 6: недооценка сложности интеграций
Доработка, которая выглядит локальной (например, изменить форму документа), часто затрагивает интеграции — обмен с сайтом, маркетплейсами, банком, ПРРО. Если на этапе оценки эти связи не учли, реальный объём работы раскрывается уже в процессе, и бюджет растёт непредсказуемо.
SATELION перед оценкой стоимости доработки проверяет, с какими интеграциями связана задача — это занимает время до старта, но исключает самый болезненный сценарий разрастания бюджета в середине проекта.
Ошибка 7: выбор исполнителя исключительно по самой низкой цене
Самое дешёвое предложение на доработку BAS часто означает отсутствие специализации именно на BAS — исполнитель учится на задаче клиента, а не применяет уже наработанный опыт. Результат — больше часов на ту же задачу и более высокий риск ошибок первого-второго пункта этого списка.
Собственная WMS-система SATELION, построенная на BAS с нуля той же командой, которая выполняет клиентские доработки, — практическая проверка того, что команда выдерживает сложные кастомные задачи, а не только простые правки форм.
Как не удвоить бюджет: короткий чек-лист
Перед стартом доработки проверьте: есть ли чёткое ТЗ с примерами результата, контролирует ли проект PM (а не только прямой контакт с разработчиком), заложено ли тестирование на копии базы, учтены ли связанные интеграции, и будет ли документация изменений частью результата, а не дополнительной услугой.
Если на эти пять вопросов нет уверенного ответа "да" ещё до подписания сметы — именно там прячется будущее удвоение бюджета.
Доработка BAS удваивает бюджет не из-за непредсказуемой сложности, а из-за повторяющихся, хорошо известных ошибок процесса — размытого ТЗ, отсутствия PM-контроля, тестирования на боевой базе, игнорирования интеграций. Все семь решаются на этапе подготовки проекта, а не после того, как бюджет уже превышен.