Мы теряем контроль над сложной 1С:ERP. Что делать?

После двенадцати предыдущих историй может возникнуть соблазн решить проблему самым современным способом. У предприятия есть тысячи технических заданий, десятки тысяч задач сопровождения, Git, расширения, протоколы совещаний, настройки, тесты, отчёты и многолетняя история продуктивной работы. Кажется логичным собрать всё это, загрузить в систему искусственного интеллекта и попросить: «Разберись, почему наша 1С:ERP устроена именно так». Проблема состоит в том, что из большой кучи корпоративных артефактов...

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

После крупного изменения в 1С:ERP есть момент, когда проектная команда получает почти идеальную картину. Разработка завершена, сценарии пройдены, регрессионные тесты зелёные, релиз установлен, задача переведена в статус «Выполнено». Через несколько дней пользователь открывает документ и говорит: «У меня всё работает по-старому». Разработчик проверяет код и уверяет, что исправление точно вошло в поставку, тестировщик показывает успешный сценарий, администратор подтверждает установку релиза. Каждый...

После крупного обновления 1С:ERP есть момент, который почти физически ощущается как облегчение. Команда завершила перенос собственных изменений, тестовая база поднята, регрессионный комплект запущен, и на экране один за другим появляются зелёные результаты. Допустим, пройдено 486 сценариев из 486, критических ошибок нет, документы создаются, статусы меняются, интеграции отвечают, отчёты формируются. В этот момент очень легко сделать вывод: если старые тесты снова зелёные, значит система сохранила правильное поведение...

Обновление старой кастомизированной 1С:ERP почти никогда не начинается с ощущения, что сейчас придётся заниматься историческим расследованием. На старте задача выглядит вполне технически: есть рабочая конфигурация предприятия, есть новый релиз 1С:ERP, нужно выполнить сравнение, разобрать конфликты, перенести необходимые изменения и проверить результат. Разработчики знают технологию обновления, аналитики понимают предметные области, тестовая база подготовлена, поэтому сама процедура кажется сложной, но вполне инженерной...

В старой кастомизированной 1С:ERP рано или поздно находится доработка, существование которой начинает раздражать всех сразу. Пользователи считают её устаревшей, разработчик видит лишний код, архитектор хочет упростить систему, а в новой версии типовой конфигурации, возможно, уже появился похожий механизм. Кто-нибудь задаёт вполне разумный вопрос: «А что вообще случится, если мы это удалим?» Кажется, что ответ должен дать обычный технический анализ зависимостей. Нужно посмотреть, кто вызывает процедуру,...