Как неверная постановка задачи утопила проект по переносу в 1С (и как мы (MoscowSoft) нашли выход за 2 минуты)

Это был самый конец января. К нам обратился заказчик с задачей — перенести данные из конфигурации «Управление нашей фирмой» (УНФ) в «ERP» (Управление предприятием). Они просто купили у нас соответствующую обработку, и только потом вышли на связь с просьбой помочь с переносом.

Запрос выглядел как рутина. Клиент приобрёл инструмент, теперь нужно было его применить. «Что тут может пойти не так?» — подумал я тогда.

Ну что ж, продали. А дальше началось самое интересное...

Чтобы был контекст, объясню про тариф. Клиент купил обработку по тарифу «Лайт».

Что это значит на практике:

Для кого этот тариф идеален? Писать такую обработку с нуля. Но на это спокойно уходит один, два, а то и три месяца работы. Вот такая суть. И казалось бы, клиент всё сделал разумно. Купил инструмент, чтобы сэкономить.

Мы всегда готовы дать совет и помочь нашим клиентам в рамках возможностей, даже по «Лайту». Но в этой истории диалог пошёл по другому руслу с самого начала.

Но, как выяснилось дальше, ключевое слово здесь — «опытный специалист».

Звонок. В голосе клиента — недоумение и претензия: «У вас обработка не работает! Ничего не переносится! Почему?»

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

Это была первая диагностическая гипотеза. Версия? Релиз? Конфигурация? Нужно было проверить фундамент, прежде чем искать трещины в стенах.

Разговор пошёл дальше. Я начал перебирать причины: «Проблема может быть в ошибках учёта в самой исходной базе...»

В ответ прозвучала железная, на первый взгляд, контраргументация:

«Мы уже пробовали! У нас не одна база — мы тестировали на десятках баз! И везде одни и те же ошибки, ничего не получается!»

Логика клиента была ясна: раз ошибка повторяется на множестве независимых баз, значит, виноват не «мусор» в данных, а сам инструмент. Звучало убедительно.

Я снова объяснил суть тарифа «Лайт» и предложил путь к решению: апгрейд до тарифа PRO. Сделайте апгрейд — и вы получите 4 месяца поддержки и обновлений. Мы подключимся, разберёмся с ошибками, всё проверим. Для этого, естественно, понадобится доступ к вашим базам».

Затем последовали вопросы про экспресс-техподдержку (видимо, хотелось побыстрее).

И тут диалог упёрся в совершенно иное русло. Клиент начал спорить о релизах:

«У нас УНФ версии 3.0.13. А у вас, наверное, обработка для 3.0.12. Скиньте нам актуальную!»? (3.0.12 отгрузили на момент покупки, а Заказчик просил 3.0.13, когда у клиента была 3.0.12 на момент покупки и осталась в последствии)

Мой ответ был по регламенту: «Нет, просто так скинуть не могу. Отправить новую версию обработки могу только в рамках действующих обновлений по тарифу PRO».

Посыпались обвинения: «Вы нам отгрузили неактуальную версию!»

Пришлось включаться в режим техподдержки и объяснять процессы: «У нас автоматическая ежедневная выгрузка. Обработка на сайте обновляется каждый день и всегда соответствует последней выложенной нами версии. Она физически не могла быть «неактуальной» на момент скачивания».

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

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

На следующий день — новый звонок. Мужской голос: «Здравствуйте, нас интересует перенос из УНФ в ERP. Проконсультируете?»

Отвечаю: «Да, меня зовут — Сергей, какая у вас задача?»

Он рассказывает: «Мы планировали перейти с УНФ на ERP ещё в новогодние праздники. Но подрядчик нас подвёл. Расскажите про ваши правила, хотим сделать проект».

Сейчас уже 6 февраля 2026 года, а проект стоит.

Ситуация один в один с нашей вчерашней проблемой. Я решил проверить:

«Понимаете, мы узко специализируемся на перосах. Бывает такое что у нас покупают готовый инструмент для проекта, а потом уже конечный заказчик, столкнувшись с проблемами, звонит нам напрямую. Это не ваша ли история? Какая фирма работала?»

Он называет название. Всё сходится. Это клиент того самого заказчика.

Заказчик просто ахнул, когда я буквально угадал всю ситуацию: «Так это же вы у нас обработку покупали!». Мы начали обсуждать детали, и вскрылась главная ошибка всего проекта.

Оказалось вот что: Наш заказчик (подрядчик) согласился на условия конечного клиента — перенести документы за два года.

Я чуть не поперхнулся. Так делать вообще нельзя. Это тупиковый путь, который гарантированно ведёт к провалу.

Почему? В чём суть:

Вот почему у подрядчика «ничего не получилось». Он вписался в технически неверную, кабальную постановкой задачи. Не имея нашего опыта, он обрёк себя и проект на провал.

Корень проблемы оказался не в нашей обработке, и даже не столько в тарифе, а в фатальной ошибке на этапе планирования, которую опытный специалист увидел бы сразу.

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

Но что сделали эти «опытные»? Они просто подписались на прямую, неверную задачу, не разбираясь. И, скорее всего, взяли за это пару миллионов рублей, которые в панике решили спасти, обработкой за 30 тыс. руб . При этом они даже не представляли себе реальной сложности переноса документов за 2 года.

И только когда уже припекло (в районе 22-25 января), они в панике купили у нас правила. Их расчёт был на волшебную таблетку — что наша обработка магическим образом спасёт ситуацию, которую они сами усугубили месяцем безрезультатной работы и неверным техзаданием.

По сути, они продали клиенту «космический корабль», не зная, как собрать велосипед.

Клиент заполнил наш опросник. Я посмотрел — всё было понятно для первичной оценки и передал специалисту для детального расчёта. Общение с клиентом перешло в переписку.

И вот тогда он и написал ту самую ключевую фразу, которая всё ставит на свои места:

«Год в УНФ у нас никогда не закрывался».

Меня это, честно, удивило. Если год не закрывался — это прямой признак того, что в базе накоплены некорректные данные, есть незавершённые операции. Это не просто “не очень”, это фундаментальная проблема качества учёта.

И вот тут вспоминается аргумент того подрядчика доказывая, что проблема в нашей обработке, он заявлял: «Мы проверили на ДЕСЯТКАХ баз! Везде ошибки!» — с которым он пытался обвинить наш код. Он пытался этим аргументом продавить, обмануть, проманипулировать: мол, раз везде одно и то же — виноват ваш код, а не наши данные.

А теперь выяснилось, что у конечного клиента — этого самого «десятка» — база в принципе в запущенном состоянии с некорректным учётом! И они, беря миллионы, даже не проверили этого.

Получается гениальная ирония:

Это смешно и грустно одновременно. Смешно — из-за абсурдности ситуации. Грустно — потому что это классическая история, когда подрядчик, не обладая реальной экспертизой в предметной области, берётся за сложный проект, не может выполнить его своими силами, а потом пытается переложить вину на инструмент или вендора.

Клиент раскрыл схему учёта:

Задача стояла — перейти из УНФ в ERP. И все, включая первого подрядчика, бились именно над этим.

И тут пришло озарение. Я задался вопросом: почему, глядя на эту схему, подрядчик не предложил очевидный для эксперта вариант?

Я предложил стратегию, от которой клиент буквально ахнул от восторга:

Реакция клиента была мгновенной и восторженной: «Ага! Точно! Как же я сразу не подумал!».

Мы начали анализировать статистику УНФ, чтобы убедиться, что все ключевые объекты учёта есть в «Бухгалтерии» и при переносе из БП 3.0. не останется потерянных важных данных в УНФ, которых будет не хватать для полноценной работы в ERP.

Когда конечный клиент всё рассказал, у меня в голове сначала не сразу всплыл тот негативный разговор с их подрядчиком. Первой мыслью было: «Блин, а как бы им помочь? Может, позвонить тому заказчику, предложить экспресс-техподдержку? Мы бы в её рамках быстро всё привели в порядок».

А потом я вспомнил. Вспомнил тон того диалога, беспочвенные обвинения и нежелание слушать. Стало ясно, что этот заказчик — «неблагонадёжный». Не в смысле “неплатёжеспособный”, а в смысле “неконструктивный партнёр”. Тот, с кем даже при всём желании работать тяжело и неприятно.

Думал даже пойти окольным путём: затянуть с этим исходным клиентом согласование оценки и «втихую», пока мы «согласовываем договор», помочь тому самому подрядчику исправить ситуацию. Чтобы он выправил проект, а мы остались «в тени», просто как вендор, который в итоге помог.

Но я решил не делать так. Именно в тот момент, когда вспомнил характер того общения. Потому что такая «тихая помощь» поощрила бы непрофессионализм и хамство изначального подрядчика. Она бы показала, что можно накричать, обвинить, а потом тебе всё равно помогут. Это неверный сигнал для рынка и для нас самих.

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

Итог анализа:

Перенос в ERP возможен. Причём не из проблемной УНФ, а из «Бухгалтерии», где данные корректные и чистые. Это технически проще и надёжнее. Ошибки первого подрядчика — в незнании и в нежелании разобраться.

Что дальше:

Эта история — не про один неудачный проект. Это симптом системной проблемы в сфере внедрения 1С.

Реальность такова: Крупные фирмы-франчайзи часто берут сложные проекты (за 2, 5, 10 миллионов), но поручают их проектным командам из стажёров под руководством одного занятого или не достаточно компетентного руководителя. Такие команды не обладают узкой экспертизой (например, в переносах данных). Они не могут дать правильный совет на старте, не видят альтернативных путей, а когда всё летит в тартарары — ищут виноватых на стороне. Именно из-за этого Заказчики плюются и начинают ненавидеть всех «одинесников» подряд.

Эта ситуация — не редкий баг, а типичная системная ошибка в нашей сфере.

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

Мораль для Заказчиков: Спрашивайте не только «сколько стоит», а «кто конкретно и с каким опытом будет это делать?». Иначе получите команду стажеров после весенней практики, с зарплатой в 20 тыс., на проекте за который заплатили 5 млн.

Мораль для коллег: Не бойтесь сказать «это делается не так» или «давайте поищем другой путь». Это не слабость. Это и есть профессионализм, за который клиенты в итоге платят больше и благодарят годами. А те, кто берёт «пару миллионов», не думая, в итоге остаются с судами и испорченной репутацией.

Мораль для рынка: Профессионализм — не объем организации. Он — в глубине экспертизы, в честном желании помочь и в принципиальности. Даже если для этого иногда приходится сказать «нет» тому, кто кричит громче всех.

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

Еще если вы Заказчик в поисках подрядчика, то поставьте задачу перенести все документы за 10 лет и если Вам подрядчик не предложат альтернативу — бегите. Железный чек на благонадежность ©LEGIT)

И знайте, что есть команды, которые работают иначе.