Коллеги, хочу поделиться свежим кейсом. Пришло на ревью ТЗ на внедрение 1С:ЗУП КОР. Открываю — и понимаю, что документ написан так, будто внедряется изолированная система для одной компании. А параллельно утверждена Концептуальная архитектура учётно-управленческого контура Группы, где ЗУП — это часть единой экосистемы из 11 организаций с жёсткими правилами интеграции.

И началось 🔍

Что не сходилось

1. Интеграция «точка-точка» вместо шины В ТЗ — прямые обмены между ЗУП и десятком систем. А по архитектуре — только Apache Kafka + 1С:Шина, никаких point-to-point. На уровне политик ИТ-блока запрещено.

2. Мифическая «1С:ERP УХ» В ТЗ упоминается гибрид, которого не существует. В архитектуре это две разные системы: 1С:УХ — финансовый мозг и мастер фин. НСИ, 1С:ERP — операционное ядро. Автор ТЗ их просто смешал.

3. ЗУП сам себе мастер НСИ Требования HR говорят: «настройте способы отражения по МВЗ, ЦФО, статьям затрат внутри ЗУП». А по архитектуре — финансовое НСИ создаётся только в 1С:УХ, а маппинг «Подразделение → ЦФО» делается в схеме 1С:Шины. ЗУП должен оставаться типовым.

4. «Универсальный интеграционный модуль» Классика. В ТЗ — кастомный модуль для обмена между конфигурациями. В архитектуре — штатные узлы \KafkaИсточник/\KafkaНазначение\ в 1С:Шине, без разработки адаптеров.

5. Границы проекта ТЗ — только на одно ООО, а архитектура — единый контур ЗУП на все 11 организаций Группы.

Что сделали

Переписали ключевые разделы: - Обновили границы проекта - Переписали Таблицу 13 «Интеграционные потоки» — 22 системы отдельными строками, у каждой механизм обмена «Apache Kafka + 1С:Шина» и конкретный топик - Скорректировали требования к НСИ: ЗУП — только потребитель, мастер — УХ - Добавили требования к DLQ, Schema Registry, идемпотентности (RTO/RPO из архитектуры) - Убрали «1С:ERP УХ», вернули корректную терминологию

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

- Спагетти-интеграцию, которую потом годами распутывать - Доработки там, где можно было остаться на типовом функционале - Конфликты на приёмке, потому что «мы делали по ТЗ, а вы хотели по-другому»

Правило простое: прежде чем писать ТЗ — откройте концептуальную архитектуру. Если её нет — сначала сделайте её. Иначе проект обречён на переделки.

Коллеги, а у вас бывали такие «несостыковки» между ТЗ и архитектурой? Как разруливали? 👇

#1С #ЗУП #Архитектура #Kafka #Интеграция #ИТ #ЦифроваяТрансформация #УправлениеПроектами #Кейс #BestPractices