Оставьте заявку
Поможем подобрать оптимальное решение для автоматизации бизнеса и достичь новых высот в эффективности управления.
318 доработок и один дедлайн, который нельзя сдвинуть
В военно-полевой медицине есть правило: когда раненых больше, чем рук, их сортируют на три группы. Кого спасать сейчас, иначе погибнет. Кто тяжёлый, но подождёт без фатальных последствий. И кому при нынешних возможностях уже не помочь. Звучит жестоко. Но именно эта холодная сортировка спасает больше всего людей, когда помочь всем сразу физически невозможно. До неё помогали тому, кого первым принесли, и пока врач возился с одним почти безнадёжным, рядом умирали трое, кого можно было спасти за минуты.
Эта же логика однажды решила судьбу проекта на 318 требований с дедлайном, который нельзя было сдвинуть.
К нам пришёл за помощью торговый дом, крупный игрок в своём сегменте. Несколько регионов, до трёхсот пользователей в Москве, Воронеже и Краснодарском крае. Десятки внешних связей: комбинаты, склады ответственного хранения, транспортные компании, торговые сети, государственные системы. Задача на первый взгляд понятная для любого, кто работал с 1С: перейти с устаревшей редакции 1С: ERP 2.4 на актуальную 2.5.
Звучит как техническое обновление. На деле это оказалось одной из самых напряжённых историй про приоритизацию, которые я видел.
Когда мы стали разбираться, всплыли цифры. Текущая система, та самая 2.4, за годы работы обросла индивидуальным кодом. В реестре оказалось порядка 424 бизнес-процессов и 318 требований, которые нужно так или иначе перенести или переосмыслить в новой системе. Около пятидесяти точек интеграции с внешним миром. И поверх всего этого жёсткий, неподвижный срок: регламентированный учёт должен заработать на новой системе с первого января 2027 года. А стартовать проект мог только в середине 2026 года.
Триста восемнадцать требований. Полгода с небольшим на моделирование, разработку, миграцию, тестирование, обучение и запуск. И дедлайн, который нельзя сдвинуть, потому что он завязан на смену финансового года и на регламентированную отчётность, а её сроки определяет не заказчик и не мы.
Эта же логика однажды решила судьбу проекта на 318 требований с дедлайном, который нельзя было сдвинуть.
К нам пришёл за помощью торговый дом, крупный игрок в своём сегменте. Несколько регионов, до трёхсот пользователей в Москве, Воронеже и Краснодарском крае. Десятки внешних связей: комбинаты, склады ответственного хранения, транспортные компании, торговые сети, государственные системы. Задача на первый взгляд понятная для любого, кто работал с 1С: перейти с устаревшей редакции 1С: ERP 2.4 на актуальную 2.5.
Звучит как техническое обновление. На деле это оказалось одной из самых напряжённых историй про приоритизацию, которые я видел.
Когда мы стали разбираться, всплыли цифры. Текущая система, та самая 2.4, за годы работы обросла индивидуальным кодом. В реестре оказалось порядка 424 бизнес-процессов и 318 требований, которые нужно так или иначе перенести или переосмыслить в новой системе. Около пятидесяти точек интеграции с внешним миром. И поверх всего этого жёсткий, неподвижный срок: регламентированный учёт должен заработать на новой системе с первого января 2027 года. А стартовать проект мог только в середине 2026 года.
Триста восемнадцать требований. Полгода с небольшим на моделирование, разработку, миграцию, тестирование, обучение и запуск. И дедлайн, который нельзя сдвинуть, потому что он завязан на смену финансового года и на регламентированную отчётность, а её сроки определяет не заказчик и не мы.
Триста восемнадцать раненых
Проект перехода с 2.4 на 2.5 при таком объёме и таком дедлайне это и есть полевой госпиталь. Триста восемнадцать требований это раненые. Рук, то есть времени и людей, на всех сразу не хватает физически. И если действовать по принципу «делаем то, что важнее для того, кто громче просит», проект погибнет: к первому января не заработает критическое, потому что силы уйдут на второстепенное.
Поэтому первое, что нужно было сделать, это не начать разработку. А провести триаж.
Поэтому первое, что нужно было сделать, это не начать разработку. А провести триаж.
Три группы требований
Мы разложили 318 требований на три контура.
Критический контур. То, без чего первого января бизнес просто остановится или нарушит закон. Регламентированный учёт, НДС, налог на прибыль, закрытие периода, отчётность. Ключевые операционные процессы: закупки, продажи, отгрузки, склад, казначейство. Критические интеграции, без которых не пойдёт документооборот с госсистемами и партнёрами. Это операционная, её делаем в первую очередь, любой ценой, к дедлайну.
Важный контур второй волны. То, что серьёзно нужно бизнесу, но без чего можно прожить первые недели или месяцы после запуска. Удобные механизмы, к которым привыкли пользователи, но которые не блокируют работу. Часть отчётности, которая важна, но не регламентирована жёстким сроком. Это вторая очередь, сразу после запуска критического контура.
Контур пересмотра. И вот это самое интересное и самое неудобное для заказчика. Часть из 318 требований это механизмы, которые в старой системе нарастили за годы, к которым привыкли, но которые в новой архитектуре либо не нужны, либо реализуются принципиально иначе. По таким требованиям правильный ответ не «переносим», а «давайте сначала договоримся, нужно ли это вообще в новой системе, или это привычка, которую пора отпустить».
Третья группа всегда вызывает сопротивление. Потому что каждое из этих требований кому-то дорого. Кто-то годами работал с этим механизмом, он ему удобен, и он искренне не понимает, почему теперь надо обсуждать, а не просто перенести. Это нормально. В триаже всегда тяжелее всего объяснить, почему этот раненый подождёт.
Критический контур. То, без чего первого января бизнес просто остановится или нарушит закон. Регламентированный учёт, НДС, налог на прибыль, закрытие периода, отчётность. Ключевые операционные процессы: закупки, продажи, отгрузки, склад, казначейство. Критические интеграции, без которых не пойдёт документооборот с госсистемами и партнёрами. Это операционная, её делаем в первую очередь, любой ценой, к дедлайну.
Важный контур второй волны. То, что серьёзно нужно бизнесу, но без чего можно прожить первые недели или месяцы после запуска. Удобные механизмы, к которым привыкли пользователи, но которые не блокируют работу. Часть отчётности, которая важна, но не регламентирована жёстким сроком. Это вторая очередь, сразу после запуска критического контура.
Контур пересмотра. И вот это самое интересное и самое неудобное для заказчика. Часть из 318 требований это механизмы, которые в старой системе нарастили за годы, к которым привыкли, но которые в новой архитектуре либо не нужны, либо реализуются принципиально иначе. По таким требованиям правильный ответ не «переносим», а «давайте сначала договоримся, нужно ли это вообще в новой системе, или это привычка, которую пора отпустить».
Третья группа всегда вызывает сопротивление. Потому что каждое из этих требований кому-то дорого. Кто-то годами работал с этим механизмом, он ему удобен, и он искренне не понимает, почему теперь надо обсуждать, а не просто перенести. Это нормально. В триаже всегда тяжелее всего объяснить, почему этот раненый подождёт.
Развилка: перенести всё или построить заново
В таких проектах есть фундаментальная развилка, и заказчики на ней часто тянут не в ту сторону.
Соблазнительный путь: давайте перенесём всё как есть. У нас работает 318 механизмов, мы к ним привыкли, перенесите их один в один в новую систему, и мы продолжим работать как раньше, только на свежей редакции.
Это путь в пропасть, и вот почему. Старая система стала неподдерживаемой именно потому, что её закопали в индивидуальный код. Каждая доработка отдаляла её от типовой 1С: ERP, и в какой-то момент обновлять её стало невозможно: любое обновление от вендора конфликтовало с доработками. Если перенести все 318 доработок один в один в новую систему, мы получим ровно ту же самую неподдерживаемую систему, только версией новее. Через три-четыре года она опять окостенеет, и снова потребуется болезненный переход. Мы потратим полгода и миллионы, чтобы вернуться в ту же точку.
Поэтому мы предложили принцип, который звучит просто, но дорого даётся в переговорах: максимально использовать типовой функционал новой системы, а индивидуальные доработки делать только там, где без них реально нельзя, и только после того, как подтвердили, что типовой механизм задачу не закрывает.
На практике это означает, что по каждому из спорных требований идёт разговор: а как эта задача решается в типовой 2.5? Если решается, пусть и чуть иначе, чем привыкли, берём типовое и отпускаем привычку. Если действительно не решается, тогда дорабатываем. Это медленнее на старте, потому что требует обсуждения, а не механического переноса. Но это единственный способ получить на выходе систему, которую можно будет обновлять, а не очередной памятник доработкам.
Соблазнительный путь: давайте перенесём всё как есть. У нас работает 318 механизмов, мы к ним привыкли, перенесите их один в один в новую систему, и мы продолжим работать как раньше, только на свежей редакции.
Это путь в пропасть, и вот почему. Старая система стала неподдерживаемой именно потому, что её закопали в индивидуальный код. Каждая доработка отдаляла её от типовой 1С: ERP, и в какой-то момент обновлять её стало невозможно: любое обновление от вендора конфликтовало с доработками. Если перенести все 318 доработок один в один в новую систему, мы получим ровно ту же самую неподдерживаемую систему, только версией новее. Через три-четыре года она опять окостенеет, и снова потребуется болезненный переход. Мы потратим полгода и миллионы, чтобы вернуться в ту же точку.
Поэтому мы предложили принцип, который звучит просто, но дорого даётся в переговорах: максимально использовать типовой функционал новой системы, а индивидуальные доработки делать только там, где без них реально нельзя, и только после того, как подтвердили, что типовой механизм задачу не закрывает.
На практике это означает, что по каждому из спорных требований идёт разговор: а как эта задача решается в типовой 2.5? Если решается, пусть и чуть иначе, чем привыкли, берём типовое и отпускаем привычку. Если действительно не решается, тогда дорабатываем. Это медленнее на старте, потому что требует обсуждения, а не механического переноса. Но это единственный способ получить на выходе систему, которую можно будет обновлять, а не очередной памятник доработкам.
Ещё одна сложность: нельзя заморозить старое
Есть деталь, которую недооценивают почти все, кто впервые делает миграцию такого масштаба. Старую систему нельзя заморозить на время перехода.
Кажется логичным: мы взяли данные на какую-то дату, перенесли в новую систему, запустились. Статический перенос. Но так не бывает в живом бизнесе. Пока полгода идёт проект, старая система 2.4 продолжает работать и продолжает меняться. В ней возникают обязательные изменения: новые требования законодательства, изменения в документообороте, в логистических схемах, во внешних обменах. Их нельзя не делать, потому что бизнес работает прямо сейчас, и закон меняется прямо сейчас.
Это значит, что мы переносим не статичную картинку, а движущуюся цель. Пока строим новую систему, старая уезжает вперёд. И проект должен учитывать движение двух систем одновременно, а не разовый перенос на дату. Это как пересаживать пассажиров из одного поезда в другой, когда оба идут на полном ходу и ни один нельзя остановить.
Эта мысль, когда мы её проговорили, для заказчика была важной. Потому что она объясняет, почему проект нельзя спланировать как простое «перенесли и запустили», и почему так важна дисциплина приоритизации. Каждая лишняя доработка в критическом контуре это не только время на неё саму. Это ещё и риск, что за время её разработки старая система уедет ещё дальше, и придётся догонять.
Кажется логичным: мы взяли данные на какую-то дату, перенесли в новую систему, запустились. Статический перенос. Но так не бывает в живом бизнесе. Пока полгода идёт проект, старая система 2.4 продолжает работать и продолжает меняться. В ней возникают обязательные изменения: новые требования законодательства, изменения в документообороте, в логистических схемах, во внешних обменах. Их нельзя не делать, потому что бизнес работает прямо сейчас, и закон меняется прямо сейчас.
Это значит, что мы переносим не статичную картинку, а движущуюся цель. Пока строим новую систему, старая уезжает вперёд. И проект должен учитывать движение двух систем одновременно, а не разовый перенос на дату. Это как пересаживать пассажиров из одного поезда в другой, когда оба идут на полном ходу и ни один нельзя остановить.
Эта мысль, когда мы её проговорили, для заказчика была важной. Потому что она объясняет, почему проект нельзя спланировать как простое «перенесли и запустили», и почему так важна дисциплина приоритизации. Каждая лишняя доработка в критическом контуре это не только время на неё саму. Это ещё и риск, что за время её разработки старая система уедет ещё дальше, и придётся догонять.
Что показывает экспресс-обследование здесь
Этот заказчик уже прошёл несколько волн интервью и обследований до нас. Люди устали от вопросов. Поэтому наша задача была не устроить ещё один долгий аудит, а быстро и точно увидеть структуру проблемы.
И структура оказалась не в том, что надо перенести 318 требований с одной версии на другую. А в том, что надо провести триаж этих требований, отделить критическое от привычного, и выстроить переход волнами под неподвижный дедлайн, удерживая в голове, что старая система продолжает жить всё это время.
Это и есть компетенция, которую невозможно показать словами «у нас опытная команда». Её видно только в том, как разложена задача. Заказчик пришёл с запросом «помогите перейти на 2.5». Мы увидели, что главная задача проекта не техническая, а приоритизационная: в условиях, где всего сразу не успеть, правильно решить, что делать первым, что вторым, а что не делать вовсе.
И структура оказалась не в том, что надо перенести 318 требований с одной версии на другую. А в том, что надо провести триаж этих требований, отделить критическое от привычного, и выстроить переход волнами под неподвижный дедлайн, удерживая в голове, что старая система продолжает жить всё это время.
Это и есть компетенция, которую невозможно показать словами «у нас опытная команда». Её видно только в том, как разложена задача. Заказчик пришёл с запросом «помогите перейти на 2.5». Мы увидели, что главная задача проекта не техническая, а приоритизационная: в условиях, где всего сразу не успеть, правильно решить, что делать первым, что вторым, а что не делать вовсе.
Чем это кончилось пока
Проект на стадии, где структура определена и направление согласовано. Мы показали, что переход нужно вести волнами, с жёстким разделением на критический контур, вторую волну и контур пересмотра. Что переносить всё подряд нельзя, иначе через несколько лет вернёмся к той же неподдерживаемой системе. Что планировать нужно движение двух систем, а не разовый перенос. Впереди детальное проектирование и сам переход, и это большая работа на грани возможного по срокам.
Дедлайн первого января никуда не делся, и сдвинуть его нельзя. Но теперь хотя бы понятно, как в это окно поместиться: не пытаясь спасти всех раненых одновременно, а спасая в правильном порядке тех, кого можно спасти. В полевом госпитале это и называется работать профессионально. В проектах миграции тоже.
Дедлайн первого января никуда не делся, и сдвинуть его нельзя. Но теперь хотя бы понятно, как в это окно поместиться: не пытаясь спасти всех раненых одновременно, а спасая в правильном порядке тех, кого можно спасти. В полевом госпитале это и называется работать профессионально. В проектах миграции тоже.