Когда тебе кажется, что ты уже видел всё в мире корпоративных внедрений 1С, приходит крупная лизинговая компания и говорит: «А давайте сделаем ERP на базе 1С:Бухгалтерия 3.0, но так, чтобы всё было заточено под наши уникальные процессы, ФСБУ-25, МСФО, сложные лизинговые схемы, кредиты, страхование и прочие радости жизни». К этому вызову добавляются сложная релизная политика, требование бесшовной интеграции с действующими смежными системами и жёсткие стандарты качества, которые невозможно было обеспечить без полноценного покрытия автотестами. И вот тут начинается настоящее веселье.
Привет, меня зовут Гродская Ольга, я технический менеджер проекта, и мы в К2Тех за два года переработали типовую 1С:Бухгалтерию 3.0 и превратили её в единую ERP-систему для крупной лизинговой компании. В проекте: 250 доработок, 70 автоматизированных бизнес-процессов, 10 интеграционных потоков, переход на инвестиционную фазу в МСФО, сквозная автоматизация казначейства, лизингового портфеля, кредитов, страхования и др. Результат — поэтапный отказ от старых систем, рост точности отчётности и сокращение трудозатрат большинства служб.
Почему вообще понадобился реинжиниринг
Всё началось с изменений в отрасли: с 2022 года лизинговые компании обязаны вести учёт по ФСБУ 25. Это не просто новая галочка для отчётности — это полная перестройка учёта, особенно сложная если компания работает в десятках городов и обслуживает тысячи клиентов. До этого момента бизнес жил на двух системах: одна старая для операционки, вторая — для регучета и МСФО. Данные прыгали между базами, поддержка обеих систем стоила дорого, а ручной труд множился с каждым изменением ключевой ставки.
В какой-то момент стало очевидно: нужно что-то менять. И менять радикально. Помимо требований регулятора, у заказчика был чёткий запрос: система должна не просто соответствовать новым стандартам, но и быть заточенной под реальные бизнес-процессы компании. Никакой базовой «коробки», только живой код под живые задачи. Важный критерий — отказ от ручного труда и единообразие всех процессов. Но ещё важнее были условия старта. В системе были тысячи активных договоров лизинга, каждая операция по которым должна была точно и своевременно отражаться в отчётности. При этом данные хранились в разных структурах, а часть процессов и вовсе велась в Excel. Объединение в единую платформу было не «хотелкой», а единственным способом сохранить управляемость.
Выбор 1С:Бухгалтерия 3.0 был скорее внешним обстоятельством — платформа уже использовалась для отдельных задач, и было важно сохранить преемственность. Препятствия лежали в плоскости архитектуры: типовая конфигурация изначально не была рассчитана на подобную кастомизацию. Добавить сюда сложности с производительностью при тысячах договоров, трудоёмкость интеграций и необходимость обеспечить совместимость с регулярными обновлениями от 1С — и становится понятно, что это была не просто кастомизация, а полное переосмысление ядра системы.
Как мы подходили к задаче
С самого начала было понятно: никакой «легкой кастомизации» не получится. Система построена по принципу надстройки над типовой конфигурацией. Её основа осталась неизменной, но вся бизнес-логика лизинга реализована в дополнительных слоях, что обеспечило необходимую оптимизацию и автоматизацию. В итоге из более чем 250 доработок каждая решала конкретную задачу бизнеса, а не просто «чтобы было».
Методологически мы пошли по классическому проектному подходу с добавлением элементов agile. Иначе было нельзя: чувствительность финансовых данных, критичные сроки, строгие и изменяющиеся требования и высокий риск ошибок в отчётности. Этапы были разбиты на логические блоки. Каждый блок (аналитика, проектирование, разработка, внедрение и сопровождение) имел чёткие критерии завершения и приёмки. Аналитика заканчивалась формированием функциональных требований и детальной документацией, разработка — обязательным код-ревью и тестированием, внедрение — серией внутренних и внешних приёмочных испытаний разной направленности. Такой подход позволил снизить риски и контролировать качество на каждом шаге проекта. Мы сознательно отказались от временных решений и костылей: лучше потратить больше на старте, чем потом тратить вечность на техдолг. Это был не просто проект внедрения — это был марафон по реинжинирингу учёта, который потребовал синхронизации усилий аналитиков, консультантов и разработчиков. А ещё — запаса валерьянки.
Отдельной сложностью был ввод новых специалистов в команду: каждый “новичок” 2-4 недели изучал документацию и внутреннюю архитектуру, прежде чем начинал приносить пользу. И хоть реальные задачи ставились сразу, качественный “выхлоп” нужно было ждать. Потому как без подробного погружения было просто невозможно осилить нетиповую и уникальную логику системы. Но мы справились.
Что было критически важно для нашего клиента из-за большого объема кастома:
Единая архитектура и масштабируемость, высокое качество технического решения и безопасность владения. Без этого любой большой кастом превращается в технический долг.
Обновляемость: система после наших доработок должна была продолжать обновляться. Наши стандарты и строгое рецензирование каждого документа были нацелены на то, чтобы после нас система у заказчика оставалась полностью работоспособной и поддерживаемой.
Интеграция: доработка должна была бесшовно встроиться в текущую конфигурацию, ничего не сломав.
Высокие требования к качеству породило сложную релизную политику, в которой выделялось 4 хранилища данных, в каждом из которых тестирование проводилось отдельно.
Как мы не запутались в хаосе кастомизаций благодаря СППР
Еще один важный пункт в подготовке проекта, когда требований больше, чем звезд на небе, а кастомные доработки – повсюду, классического «набросаем ТЗ в Excel» становится катастрофически мало. Нам нужен был способ не просто собирать требования, а структурировать их, как карту местности перед сложным походом. Таким инструментом для нас уже многие годы во многих проектах становится система проектирования прикладных решений (СППР).
Если говорить образно, на этапе проектирования мы действовали как грибники: сначала собирали все «грибы»-требования в одну корзину — результат обследования бизнес-процессов. Потом начиналась сортировка: «лисички» — в одну доработку, «подберёзовики» — в другую. Так мы ничего не теряли и раскладывали сложную логику заказчика по полочкам метаданных и конкретных задач для разработчиков.
Мы взяли за основу «1С:СППР» и серьёзно её доработали. Главная цель была — превратить проектирование из творческого хаоса в управляемый процесс.
Что это дало на практике?
Визуальная ясность. Мы видели не просто список задач, а взаимосвязи между бизнес-процессами и объектами системы. Это как получить не просто список улиц, а полноценную карту города со всеми развязками.
Управление сложностью. Стало возможным точнее оценивать сроки, видя связанность и сложность каждой доработки.
Контроль качества на входе. Технические и функциональные архитекторы могли на этапе проектирования заложить ключевые принципы: доработка не должна была сломать соседний функционал и обязана была позволять системе обновляться. Наша главная заповедь — «после нас ничего не должно гореть синим пламенем».
Унификация подходов и автоматизация рутины не избавила команду нашу от необходимости глубоко думать, но позволила сосредоточиться на качестве архитектуры, а не на оформлении документов. В проекте такого масштаба без этого было не обойтись.
Автотесты: мы заставили систему проверять себя саму
С таким уровнем кастомизации ручное тестирование каждого обновления превратилось бы в бесконечный кошмар. Представьте: после очередного изменения платформы нужно вручную проверить тысячи сценариев — от простого открытия формы до сложных регрессионных тестов. Мы пошли другим путём и внедрили автоматизированное тестирование.
Всего мы развернули более 100 сценарных тестов двух типов:
Дымовые (smoke) — быстрая проверка, что система «не сломалась» после обновления: открываются ли формы, создаются ли объекты. Что-то вроде утреннего кофе для системы — минимальный набор, чтобы понять, что она проснулась в рабочем состоянии.
Функциональные и регрессионные — уже серьёзная проверка, что новые доработки не отравили жизнь старой логике. Например, цепочка «покупка предмета лизинга – финансирование сделки» должна работать как швейцарские часы, даже если мы десять раз добавляли смежный функционал в ядро.
Это дало нам не просто «галочку» в отчёте, а три практических преимущества:
Снизили риски простоев — система сама сообщала о проблемах до того, как они достигали пользователей.
Ускорили выход обновлений — вместо дней ручной проверки получали готовый отчёт за часы.
Упростили жизнь консультантам — побочным эффектом стала автоматическая генерация видеоинструкций по всем ключевым сценариям.
Но волшебства не бывает. За каждой автоматизацией стоят люди. Развёртывание и поддержка тестов потребовали слаженной работы трёх специалистов:
Технический специалист создал инфраструктуру — настроил системы управления базами и запуска тестов.
Функциональный консультант при помощи ИИ перевёл бизнес-логику на язык сценариев.
Аналитик-тестировщик стал главным по качеству — ежедневно анализировал результаты, исправлял сценарии и держал процесс на плаву.
Мы отказались от полумер. Автотесты стали не дополнительной опцией, а полноценной системой контроля качества — ещё одним страховочным тросом в нашем марафоне по реинжинирингу.
Архитектура и ключевые блоки
В результате мы создали интегрированную ERP-систему, которая покрывает все основные процессы лизинговой компании. С архитектурной точки зрения мы ушли от монолита. Теперь каждый крупный блок отвечает за отдельное бизнес-направление: бухгалтерия, МСФО, лизинг, казначейство, страхование и т.д, которые интегрированы между собой.
Часть модулей пришлось писать с нуля. Например, учёт инвестиционной фазы раньше отсутствовал как класс — теперь это полноценный блок с автоматическим расчётом графиков, формированием проводок и поддержкой двойного учёта. Казначейство тоже прошло тотальный апгрейд: система умеет создавать заявку на расход денежных средств (ЗРДС) и платёжки по шаблонам, управлять депозитами, контролировать кассовые разрывы и учитывать минимальный неснижаемый остаток (МНО).
Чтобы обеспечить производительность, самые тяжёлые операции — расчёты по МСФО, переносы между периодами, обработка банковских выписок — были разбиты на несколько фоновых потоков.
Заново был разработан и блок трансляции МСФО, с возможностью работы с отдельными потоками данных параллельно, с возможностью отслеживания изменений в закрытых периодах нетривиальным способом и работой с разными параметрами консолидации Благодаря оптимизации алгоритмов, скорость выполнения этих операций выросла в несколько раз.
Важно: несмотря на глубину изменений, нам удалось сохранить совместимость с обновлениями 1С. Сложно, да. Но жизненно необходимо для бизнеса.
Особое внимание уделили интеграциям: система общается с внешними сервисами, банками, внутренними порталами, документооборотом. Например, казначейство теперь умеет автоматически распознавать банковские выписки, формировать платёжки, управлять депозитами. В пиковые дни скорость обработки выросла в разы — пользователи больше не выполняют вручную корректировку реестра платежей, если появляются новые срочные заявки.
Интеграции с внешними системами — это отдельный фронт работ. Система связана с 1С:ДО, банковскими шлюзами, внутренними порталами, Федеральной нотариальной палатой (ФНП), дочерними компаниями. Например, учёт залогов теперь работает в связке: документы «Передача в лизинг», уведомления, взаимодействие с ФНП. Всё это раньше выполнялось руками.
Для контроля движения денег спроектирован платёжный календарь. Он позволяет оценивать кассовые разрывы, управлять графиком оплат, видеть свободные средства на счетах с учётом депозитов и МНО. Раньше такая детализация требовала тонны работ в Excel и частично велась только по запросу.
Несколько слов о сложных местах
Автоматизация лизингового портфеля — отдельная песня. Теперь система сама распределяет входящие платежи по договорам, учитывает обеспечения, ведёт рейтинги лизингополучателей. Если раньше сотрудники вручную разбирались с корректировками и перераспределениями, то теперь всё это делает система, минимизируя ошибки и ускоряя работу.
Пожалуй, самая нетривиальная задача — автоматизация двойного учёта: РСБУ и МСФО. Разные стандарты, разные даты закрытия, разные подходы к формированию учетных моделей.
Немало сложностей было и со страхованием, с первым блоком реинжиниринга. На момент старта проекта данных для проектирования блока было мало, поэтому в итоге модуль получился не столь гибким, как хотелось бы. Если бы делали снова, то скорее всего сначала дожали бы верхнеуровневую аналитику по всем блокам, а уже потом кодили отдельные релизы.
Некоторые доработки пришлось вырезать. Например, внутренние отчёты, которые в итоге не пригодились, или узкоспециализированные сценарии бизнес-процессов, которые проще оказалось закрыть вручную. Но даже это пошло на пользу — всё лишнее вычистили на ранних этапах, чтобы не тащить в прод.
Что изменилось для бизнеса
Самое главное — компания ушла от оперативного учета в двух разрозненных системах. Теперь вся отчётность, управленческий и операционный контур работают в единой базе, что исключило рассинхрон данных и снизило издержки на сопровождение. Ретроспективный пересчёт и сквозной контроль обеспечили соответствие как российским, так и международным стандартам.
Результаты говорят сами за себя. Детализация и точность управленческой отчетности увеличено, время на обработку данных сокращено и теперь есть возможность потратить силы на более глубокий анализ данных. Самое главное, что появилась возможность действительно «видеть» бизнес: детализация результатов вплоть до конкретного предмета лизинга, визуализация по разным стандартам, прозрачность изменений для аудиторов.
Итоги и выводы
Этот проект стал отличным примером того, как глубокий реинжиниринг типовой 1С может не только соответствовать регуляторным требованиям, но и реально трансформировать бизнес-процессы крупной компании. Главное — не бояться отказаться от стандартных решений и строить систему под себя. В итоге получилась живая, гибкая и мощная, но легкая ERP, которая уже работает в промышленной эксплуатации и продолжает развиваться вместе с компанией.
Если бы делали всё заново — точно по-другому подошли бы к верхнеуровневой аналитике всех процессов в целом. И релизы дробили бы на более короткие, понятные куски: так и тестировать проще, и внедрять спокойнее. Из полезных практик: погружение новых специалистов команды длилось не меньше двух недель, иначе в такой конфигурации они просто тонут. Много времени уходит на изучение нетиповой логики.
Если вы планируете похожий проект, три совета:
Не экономьте на аналитике до начала разработки сложных блоков, особенно в тех областях, где от этого зависит гибкость реализации всей конфигурации.
Дробите релизы на максимально короткие этапы.
Обеспечьте минимальную текучку кадров и продумайте онбординг новых сотрудников.
И да, выгорание тут подстерегало на каждом шагу. Мы старались не только пилить, но и поддерживать команду: внутренняя обратная связь, признание, нормальное человеческое общение. Всё это тоже часть проекта. Без этого — никак.
Если у вас был похожий опыт реинжиниринга 1С, расскажите в комментариях — уверен, у каждого найдётся своя любимая боль (или лайфхак). А если есть вопросы по техническим деталям — пишите, обсудим!
