Каждый архитектор и руководитель 1С-проектов рано или поздно сталкивается с выбором: продолжать латать старую систему или снести всё до основания и заложить правильный фундамент.
Обычно бизнес выбирает «пластыри» – это кажется быстрее и дешевле. Но со временем система превращается в «монстра», а команда попадает в зависимость от «золотых гвоздей» – уникальных специалистов, без которых эта конструкция просто не работает.
Расскажу на реальном примере, как ошибка в архитектуре учёта объектов строительства привела к необходимости полного переписывания модуля с нуля.
Как рождаются «золотые гвозди»?
Всё начинается благими намерениями. Нужно быстро запустить блок учёта, времени на глубокое погружение и проектирование предметной области «как всегда нет». Задачи нарезаются и дописываются на лету. Что получилось в исходной системе:
• Неверный выбор базиса: Ключевая аналитика по объектам строительства велась не в справочниках и регистрах сведений, а распределялась по документам.
• Проблема с версионностью: К одному объекту создавался Заказ. При изменении условий формировался новый документ, а у предыдущего менялся статус на «Изменён».
• Разрыв связей: Так как реальные работы и движение ТМЦ/затрат уже шли, в первичных документах оставались ссылки на те самые «измененные» (по сути, недействительные) заказы.
К чему это привело?
1. Технический тупик и «лежащие» отчёты. Чтобы собрать итоговую аналитику по объекту, системе требовалось сначала поднять весь массив связанных заказов (включая все их исторические и измененные версии), сопоставить их актуальность и только потом вывести цифры. Со временем объем данных вырос, и формирование отчётов превратилось в долгое ожидание с высокой нагрузкой на базу данных.
2. Появление «Золотого гвоздя». Когда система становится хаотичной, единственным способом поддержать её работоспособность становится человеческий фактор.
В данном случае этим «золотым гвоздём» стала я. Только один человек в компании досконально понимал:
• В каком порядке нужно провести документы, чтобы не «поехала» аналитика;
• Какая логика заложена в связях цепочек документов;
• Где и что нужно ручками подправить, чтобы отчёт не сдублировал данные.
Спойлер: Быть «золотым гвоздем» — приятно для эго, но губительно для процессов. Ты становишься бутылочным горлышком, а бизнес несет колоссальные риски.
Почему «пластыри» больше не работают?
Попытка «дописать ещё один отчёт, который будет правильно фильтровать измененные заказы» – это попытка заклеить пластырем трещину в несущей стене. Это создаёт новые кастомные алгоритмы, не поддающиеся стандартной документации и поддержке.
Решение: Полный рефакторинг и переписывание структуры Управления объектами строительства с нуля.
Что меняем в новой архитектуре:
1. Вынос аналитики в регистры и справочники: Ключевая сущность объекта и его состояния отделяется от документов.
2. Грамотная модель версионирования: Отказ от формирования «дублирующих» заказов в пользу корректного регистра сведений или нормальной структуры статусов без разрыва ссылочной целостности.
3. Прозрачная модель данных: Поддержка отчётов на уровне прямых и быстрых запросов к регистрам накопления/сведений без сложных обходов исторических массивов.
4. Снижение зависимости от эксперта: Логика должна быть прозрачной, а алгоритмы – стандартными и задокументированными.
Резюме для руководства и архитекторов.
Если ваша поддержка системы 1С тратит 80% времени не на развитие, а на поиск «почему отчёт вывел не те цифры», а вся работа держится на уникальных знаниях одного-двух сотрудников – вы в зоне риска.
Надстройка нужна для локального закрытия горящей задачи. Переработка архитектуры с нуля необходима, когда старая логика начинает тормозить развитие бизнеса и генерировать технический долг.
Не бойтесь признать, что старый фундамент не подходит. Иногда проще и дешевле построить заново, чем бесконечно укреплять то, что изначально стояло на песчаной подушке.