Есть одна тема, которая вроде бы не про BIM/ТИМ, ИСУП и цифровые сервисы напрямую, но на практике сильно влияет на то, как быстро решаются вопросы в цифровой среде.
Это культура постановки вопросов и общения в рабочих чатах. Да-да, о таких вещах тоже надо, оказывается, договариваться и обсуждать правила взаимодействия.

Мы видим это сразу в нескольких местах: на первой линии техподдержки ИСУП, при отладке наших контрольных таблиц УКСа, а также в многочисленных рабочих чатах с коллегами.
И закономерности, увы, складываются.
---
Заявка в техподдержку может выглядеть примерно так: «Не работает».
Что именно не работает, на каком объекте, что делал пользователь, что увидел на экране – неизвестно 🤷🏻‍♂️
В результате вместо решения проблемы специалист сначала звонит заявителю и выясняет – в чём, собственно, заключается проблема. При этом уточнение обстоятельств может занять времени кратно больше, чем само решение проблемы.

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

Не исключено, что автор сообщения мысленно ставит своеобразную галочку в списке своих задач: сообщение в чат отправлено – значит, «я сообщил».
А адресат в это время может вообще в душé не ведать, что обращение было адресовано ему и что от него ждут каких-то действий.
В итоге вопросы, которые можно было бы решить достаточно быстро, начинают жить в переписке своей отдельной жизнью… а иногда и помирать.

В отличие от инструкций для пользователей, опыта по наведению порядка в чатах, доведённого до состояния готового «продукта», у нас пока нет.
Из перспективных идей видится одна из самых простых – фиксировать правила взаимодействия прямо в начале рабочего чата:
– кому адресуем вопрос?
– что требуется сделать?
– к какому результату хотим прийти?
– в какой срок, если это необходимо?
В общем, всё это очень похоже на т.н. «смартование» задач.

То есть вместо:

 «Коллеги, опять проблема с документом»

желательно писать примерно так:

 «@Имя, при передаче документа возникает ошибка № __. Просим проверить причину и сообщить результат». 

По количеству символов разница небольшая, но вероятность получить желаемый результат – существенно выше.
---
Уважаемые подписчики, здесь нам особенно интересен ваш практический опыт.

Удалось ли вам выстроить удобную схему подачи заявок в техподдержку? Вводили ли вы правила общения в рабочих чатах? Может быть, используете шаблоны сообщений, ботов, регламенты или какие-то другие простые инструменты, которые действительно навели порядок?

Поделитесь рабочими решениями.
Есть ощущение, что цифровая культура начинается не с очередной информационной системы, а с довольно простого умения понятно сообщить другому человеку: что произошло и что именно от него требуется.

Мы участвуем в пилотном проекте Минстроя России по подготовке цифровых ведомостей объёмов работ (ЦВОР) на основе ЦИМ.

И по ходу работы столкнулись с вопросом, который, кажется, возникает почти в любом пилоте: как сделать так, чтобы накопленные знания не остались только в головах его участников?

 
Сначала задача выглядела вполне прикладной. Чтобы не пытаться автоматизировать всё и сразу, решили двигаться от тех работ, которые сильнее всего влияют на стоимость объекта:
1. определить наиболее капиталоёмкие позиции по разделам АР, КР и ОВИК;
2. понять, какие ГЭСН за ними стоят;
3. определить, какие данные нужны для выбора конкретной нормы и расчёта объёма;
4. разобраться, как связать элемент ЦИМ с ГЭСН – напрямую либо через код нашего классификатора;
5. на основании этого определить, какие материалы, единицы измерения и другие характеристики должны быть стандартизированы в параметрах ЦИМ.

Логика вроде бы понятная: от стоимости – к норме, от нормы – к необходимым данным, от данных – к требованиям к модели.

Но довольно быстро возник ещё один вопрос.

Допустим, мы всё это прошли. Сметчик объяснил, почему для конкретной конструкции выбрана именно эта норма.
ТИМ-специалист понял, из какого параметра модели брать объём. Вместе определили, когда элемент можно связать с ГЭСН по наименованию материала, а когда нужен классификатор.

А что останется после завершения пилота?
Настройки в программе? Человек, который «помнит, почему мы тогда сделали именно так»? Формальный отчёт?

Так появилась идея Карточки ГЭСН☝️
---

Карточка нужна не столько для фиксации самой нормы, сколько для фиксации логики принятого решения.

В ней отдельно записывается:
- что это за ГЭСН и к какому разделу он относится;
- какие качественные характеристики элемента нужны, чтобы выбрать именно эту норму;
- откуда в ЦИМ брать объём и как переводить его в единицу измерения ГЭСН;
- как связать норму с элементом модели – напрямую или через классификатор;
- что делать с многослойными элементами;
- чем проверить правильность полученной связи и какой у неё статус.

То есть карточка отвечает не только на вопрос «что настроили?», но и на гораздо более полезный вопрос – «почему настроили именно так?»

Причём она специально разделяет две вещи, которые легко смешать: данные, необходимые для выбора нормы, и данные, необходимые для расчёта объёма.
❗️Это важно, потому что наличие в модели материала и геометрии ещё не означает, что этих данных достаточно для автоматического выбора нужной расценки.
---
И вот здесь, на наш взгляд, появляется ценность, которая выходит уже за рамки одного пилота.
Если такую карточку заполнить по каждой отработанной норме, другой специалист сможет не просто получить готовый результат, а проследить ход рассуждений, согласиться с ним или указать на ошибку.

Другая организация сможет взять наши наработанные связи «элемент ЦИМ → вид работ → ГЭСН», заменить наши коды классификатора и наименования материалов своими и адаптировать правила под собственную информационную среду.
А настройки сметного ПО перестают быть чем-то, что можно передать только вместе со специалистом, который их создавал.

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

Иначе следующая команда будет проходить тот же путь заново.
А если логика решений сохранена, проверяема и пригодна для повторного использования – тогда осязаемые результаты пилота действительно начнут масштабироваться.

Цифровизация строительства: договорились сотрудничать до 2030 года 🤝

Минстрой России и Правительство Свердловской области подписали Меморандум о сотрудничестве в сфере цифровизации строительства.
Со стороны Минстроя документ подписал заместитель Министра строительства и ЖКХ РФ Константин Михайлик, со стороны Свердловской области – заместитель Губернатора Сергей Швиндт.

Но главное здесь – не ещё один документ с подписями хотя это тоже, бесспорно, важно.
Главное – договорились, куда движемся дальше.

Задача – перейти от отдельных цифровых решений к системной цифровизации строительства: связать цифровыми процессами участников и этапы инвестиционно-строительного цикла так, чтобы технологии действительно помогали делать его эффективнее, прозрачнее и качественнее.

И речь уже не только о привычных нам ТИМ и государственных информационных системах.

В планах:
– обмениваться лучшими практиками и аналитикой;
– получать методическую и консультационную поддержку Минстроя России;
– участвовать в пилотных проектах по апробации перспективных цифровых решений;
– применять ТИМ на всех этапах жизненного цикла объекта;
– создавать условия для применения решений на основе искусственного интеллекта;
– подключать к цифровой трансформации муниципалитеты и организации строительного комплекса.

По сути, меняется сам подход.
Цифровизация – это уже не про «давайте внедрим ещё одну систему», а про обмен опытом: применять в регионе проверенные федеральные решения и передавать наверх собственные успешные практики.
---
Меморандум действует до 31 декабря 2030 года, конкретные мероприятия будут появляться в протоколах, планах и дорожных картах.

Меморандум – не финал, а скорее старт. И самое интересное – увидеть, во что эти договорённости превратятся на практике в Свердловской области 👀

Пожинаем плоды объединения разрозненных таблиц заказчиков Свердловской области

Помните, как некоторое время назад мы объединили разрозненные таблицы УКС Свердловской области в единую систему?
Идея была простой: иметь оперативный доступ к актуальной информации, а не собирать её по десяткам сотрудников и сотням файлов.
И, как это часто бывает с цифровизацией, бонусы обнаружились по ходу дела

Теперь мы можем посмотреть сразу на все сметы контракта и получить общую картину, а не открывать каждый файл по отдельности. И вот что увидели, проанализировав 19 смет и ~3000 захваток.

Напомним: захватка – это единица приёмки работ, то есть технологически законченный объём работ на объекте.
Захватки формируют заказчик и подрядчик согласно Методике, утверждённой приказом Минстроя РФ 841/пр и с оглядкой на нашу Методику, которая расшифровывает подходы, установленные федеральной методикой.

☝🏻 Все проанализированные захватки условно разделились на 3 группы:

1. Сделано строго по Методике – 647 захваток
Это позиции, оформленные ровно так, как показано в примерах Методики:
– разработка грунта экскаватором в траншее по осям 1, 3, 5;
– монолитная ж/б плита в осях 1-20/А-Ж – захватка №1;
– огрунтовка основания под кровельный ковёр… в осях 1-20/А-Ж.

2. Разделение есть (и оно шире, чем описано в Методике) – 2 157 захваток
Это самая интересная группа.
Подрядчики самостоятельно выделили дополнительные элементы там, где это оказалось логичным и удобным для работы:
– Лестница Лв-1 (КР1 л.26);
– Стропильные конструкции (КР1 л.35-37);
– Кладка наружных стен из газобетонных блоков, 1 этаж;
– Перегородки в санузлах (АР л.7);
– Шахта лифта.
И знаете что? Это не ошибки. Это готовый материал для следующего шага.

3. Требует дополнительного анализа – 381 захватка
Формально захватка есть, но по названию не очень понятно, что именно включено в предмет приёмки.
Вместо конкретного вида работ в названии просто указан раздел проектной документации с добавлением слова «этап»:
– конструктивные решения;
– архитектурные решения;
– сети связи;
– сети связи и кабельные трассы;
– наружные сети.

✅ Что со всем этим делать и почему это вообще хорошо?

1. Дополнить нашу Методику.
Группа №2 показывает, какие элементы подрядчики регулярно выделяют на практике.
Лестницы, крыльца, шахты и лифты, проёмы, кладка по этажам, фасады, полы, потолки – для них в Методике пока нет отдельных правил.
Значит, будем брать реальные формулировки из практики и дополнять ими Методику. Получается, что подрядчики уже частично написали её за нас. Спасибо 🤝

2. Настроить ПО.
Виды работ, которые подрядчики стабильно выделяют на разных объектах, можно превратить в готовые пресеты для программ, формирующих захватки.
То есть не заставлять пользователя каждый раз начинать с чистого листа, а предложить проверенные шаблоны.

3. Видеть историю изменений.
Здесь особенно пригодилось то самое объединение таблиц и их ежедневное автоматическое сохранение.

Теперь мы можем увидеть, как захватка выглядела изначально: например, была одним большим монолитным блоком, а потом постепенно была разделена на несколько частей.
А если однажды мы уже поняли, что такую захватку нужно разукрупнять, то логично требовать от подрядчика сразу формировать ее в нужном виде, а не исправлять всё «по ходу дела».

Вот так обычное объединение таблиц превращается в инструмент управления и анализа.
Умеем, любим, практикуем

И цифровизируем – невзирая на!

Уважаемые коллеги и дорогие читатели!

С Днём строителя вас! Желаем стабильного потока заказов и нулевой дебиторки, чтобы каждый реализованный объект приносил не только радость созидания, но и надежный финансовый результат.
Пусть цифровизация строительства станет вашим верным помощником при решении прикладных задач и покорении новых высот.

Оставайтесь с нами на борту! Мы обещаем держать штурвал и уверенно вести вас по безопасному фарватеру в обход всех коварных нормативных мелей и организационных шхер 😉

🏗 Накануне юбилейного, семидесятого Дня строителя в Правительстве Свердловской области чествовали тех, кто каждый день помогает развивать строительную отрасль региона. Среди награждённых – и цифровые спецназовцы нашего Минстроя.

На фото (слева направо): заместитель начальника отдела ГИСОГД Эмилия Хрущелёва, главный специалист ТИМ-отдела Андрей Пруцков и главный специалист отдела ГИСОГД Татьяна Крутакова.

Эмилия Ринатовна удостоена Почётной грамоты Губернатора Свердловской области.
Награду за многолетний добросовестный труд, высокий профессионализм и вклад в развитие строительной отрасли региона вручил министр строительства и развития инфраструктуры Свердловской области Григорий Сурганов.

📜 Андрей Александрович и Татьяна Валерьевна отмечены благодарственными письмами Министерства строительства и развития инфраструктуры Свердловской области за многолетнюю добросовестную государственную гражданскую службу и в связи с профессиональным праздником.

За каждым нормативным документом, каждой цифровой системой, каждым успешно реализованным проектом стоят люди, которые делают свою работу профессионально и с полной отдачей.
Энтузиазм, неравнодушие и готовность отвечать на новые вызовы – поистине, чиновники именно с такой прошивкой нужны нам и нашей стране.

Поздравляем коллег с заслуженными наградами 💫
Пусть впереди будет ещё больше интересных задач, успешных проектов и поводов для профессиональной гордости.
Браво и – так держать!

Телеканал Россия 24 опубликовал тематический выпуск «Цифровизация в строительстве» в рамках цикла программ Есть решение.

Почти половина жилья в России строится с использованием технологий информационного моделирования. Отрасль активно применяет искусственный интеллект. В реестре отечественного программного обеспечения больше 400 продуктов предназначено для стройкомплекса.
Как новые технологии меняют процессы проектирования и возведения зданий, какие разработки предлагает бизнес и как его поддерживает государство?
Об этом расскажет Марина Громова в программе «Есть решение».

Мы начали с того, что такое ТИМ, ЦИМ и ИМ в целом. Затем разобрались с дисциплинарными ЦИМ и их связью с разделами проектной документации 💪 
Теперь спускаемся еще на уровень ниже и поговорим об элементах модели – о том, благодаря чему обычные линии на чертеже становятся для компьютера осмысленной конструкцией.

Человек смотрит на план и сразу понимает: две параллельные линии рядом – это стена.
Компьютер так не умеет.
Для него это всего лишь геометрия: отрезки, вершины, ребра, грани и координаты. Чтобы программа «увидела» в этом наборе линий стену, ей нужна дополнительная информация – семантика.

Если не усложнять, то семантика – это смысловое наполнение информации, которой дополнена графическая часть модели, их соответствие проектным решениям и нормативным требованиям; насколько достоверно содержание ЦИМ отражает существо реального объекта или проекта.

В современных САПР эта логика обычно строится на трёх уровнях – смысловом (классификация), параметрическом и связях элементов модели.
 
1. Классификация
Над геометрией появляется своего рода невидимая бирка: «Я – стена».
Само геометрическое ядро программы этого не понимает – оно работает только с телами и поверхностями. Но прикладной слой считывает этот класс и применяет нужные правила.
Без такой классификации стена для программы ничем не отличается от плиты перекрытия или случайного параллелепипеда.
 
2. Параметры
Это не просто набор характеристик вроде материала, толщины или высоты.
Параметры описывают, как именно построен элемент.
Например, стена – это результат вытягивания профиля на определенную высоту. Изменили один параметр – геометрия автоматически перестроилась. Именно так работает параметрическое моделирование.
 
3. Связи
Самая интересная часть.
Окно связано со стеной не потому, что визуально находится внутри нее, а потому, что между элементами существуют строгие математические зависимости.
Передвинули стену – окно автоматически переместилось вместе с ней.
В разных САПР это реализовано по-разному: через дерево построения, систему ограничений или другие механизмы. Но принцип один – элементы модели «знают» друг друга и друг о друге.
 
——

Закрепляем: для компьютера строительная конструкция – это не просто объёмная фигура.
Это геометрия, поверх которой добавлены:
– классификация;
– параметры;
– связи с другими элементами.
Именно благодаря этому обычный чертёж превращается в ЦИМ.
 
Если после прочтения вдруг покажется, что компьютер «думает» слишком сложно – это нормально.
На самом деле он вообще не думает – он просто очень педантично следует правилам. И именно поэтому так важно соблюдать правила сборки цифровой информационной модели объекта.
#разъяснения

Автоматизированная проверка ЦИМ – цифровых информационных моделей – становится всё ближе.

Анастасия Гусева (УКС Свердловской области) и Ольга Галитарова («Форум-групп») методично продолжают работать над тем, чтобы требования к объектам можно было проверять автоматически, без долгого ручного анализа – вот такой отличный пример B2G-взаимодействия.

На сегодня они составили перечень требований к проектной документации по детским садам. А часть из них специалисты NSR уже перевели в машинопонимаемый вид.

Теперь система умеет проверять, например:
– соответствует ли площадь помещений нормативам (не менее установленного количества квадратных метров на человека);
– соблюдены ли требования к взаимному расположению помещений (например, спальни нельзя размещать над пищеблоком).

Но для полноценной автоматической проверки нужен единый понятийный аппарат; в нашем случае – единые наименования помещений.

Здесь нам в помощь – Классификатор строительной информации (КСИ), а именно таблица Rzo «Зоны и помещения».
О работе с КСИ мы уже рассказывали: ранее специалисты УКС направляли в ФАУ «ФЦС» предложения по дополнению классификатора наименованиями помещений из действующих сводов правил.

Однако тот перечень не охватывал буквально все помещения детских садов. Поэтому мы подготовили дополнения и уточнения: ещё раз пересмотрели наименования групповых, вспомогательных и технических помещений, а также добавили категории помещений, которым раньше не было однозначного соответствия в КСИ.

Отдельная благодарность коллегам из ФАУ «ФЦС» за оперативную работу!
В классификатор уже добавлено более 30 новых наименований помещений с собственными кодами, а часть существующих позиций – уточнена и перераспределена по группам.
_____________

P. S. Если вам нужно проверить цифровую модель своего ДОУ на соответствие нормативным требованиям – вы знаете, куда обращаться

Месяц назад мы рассказывали, что сотрудники Минстроя Свердловской области и областного УКСа отправились изучать промпт-инжиниринг в строительстве.

И вот обучение позади.
Финальное тестирование сдали все: 14 из 14. Никто не сошёл с дистанции – уже хороший результат💪

Самое время рассказать, чему научились.
За месяц участники прошли 7 модулей – от знакомства с тем, как вообще работают нейросети если честно, то с токенами некоторые из нас до сих пор на «вы» 😅, до вайб-кодинга и автоматизации рабочих процессов.

Но главное – это не теория.
Каждый модуль сопровождался практикой, поэтому участники не просто слушали лекции, а:
– учились писать эффективные промпты;
– примеряли на ИИ разные роли и сценарии;
– готовили документы;
– решали рабочие задачи;
– создавали небольшие программы для автоматизации рутинных процессов.

Насколько это было полезно, уже оценит руководство по результатам деятельности 😎

—————
Обучение прошло на базе Новосибирского государственного университета и Центра искусственного интеллекта НГУ.
Если хотите организовать подобную программу для своей команды – смело обращайтесь. Коллеги помогут адаптировать обучение под ваши задачи.

🤖 Стандарт как код: почему цифровая трансформация упирается не в XML, а в лингвистику

Когда говорят о цифровизации стандартов, чаще всего всплывают форматы - XML, JSON, ReqIF. Мол, переложи текст в теги, и вопрос решён. Но презентация Сергея Трофимова (Российский институт стандартизации) вскрывает куда более глубокую проблему: главный враг машиночитаемости не бумага, а язык.

Вот несколько неочевидных точек, которые цепляют.

1. 593 тега это только начало
NISO STS, используемый ISO и IEC, содержит почти 600 элементов разметки. Это не просто «структура», а попытка оцифровать юридическую иерархию. Но проблема в том, что даже идеальный XML не гарантирует понимания. Китайский AVIC пошёл дальше, они переобучают LLM на этих стандартах, чтобы извлечь не просто текст, а семантику для PLM и ERP. То есть переводят нормы на язык инженерных систем. Это уже не оцифровка, а интеграция.

2. Матрица рисков это диагностика всей отрасли
Самый сильный слайд - таблица, где ошибки делятся по уровням:

· Лексика → подмена терминов (искажение понятий).
· Синтаксис → неверный парсинг (потеря структуры).
· Семантика → сдвиг смысла (искажение требований).
· Прагматика → ошибка применения (неверная норма).

Цифровой стандарт это не документ, а система принятия решений. И если ИИ неправильно понял слово «должен» или «рекомендуется», последствия это не баг в интерфейсе, а сбой в производственном цикле.

3. Модальность это убийца логики
«Должен», «следует», «может» - для нас привычные слова. Для модели - три разных правовых режима. Трофимов справедливо отмечает: сводить их к одной логической форме нельзя. Это требует отдельного слоя онтологий, где условие (антецедент) и действие (консеквент) не просто выделены, но и привязаны к контексту применения.

4. Российский институт стандартизации строит «цифровой полигон»
Не просто базу терминов «Ростерм» (266 000 терминов!), а конструктор документов с автоматическим выделением требований. И это уже не про чтение, а про извлечение. Когда из текста вынимают метаблок с правилами, которые можно сразу скормить CAD или BIM-системе.

Итоговая мысль из презентации: цифровая трансформация стандартов - это не перевод в PDF/A или XML. Это инженерия смысла. И успех здесь зависит не от выбранного формата, а от того, как мы формализуем иерархию, связи, модальность и условия применения.

Иначе получаем удобную, но юридически ничтожную модель. А это дороже любого бумажного архива.

#ИИ #ИИ_ИНП #TechNews  #ИНП

MАХимально на связи
подписывайтесь:
@NextGenInfrastructure

Ну что, пришло время раскрыть карты 👀

Спасибо всем, кто принял участие в опросе – как видите, мнения разделились, и это подтверждает, что рубрику Разъяснения мы запланировали не зря.
Начнём с основ.

ТИМ, ИМ и ЦИМ – это одно и то же?
Звучат похоже, пишутся через запятую, а в документах и на совещаниях их то и дело подменяют друг другом. Проектировщик говорит одно, заказчик слышит другое, а в техническом задании в итоге написано третье.

И хотя эти сокращения почему-то часто используют как синонимы, означают они совершенно разные вещи. И это не просто совпадения-сочетания букв: от правильной терминологии зависит, что вправе требовать заказчик и что именно должен передать заказчику подрядчик.

ТИМ – технологии информационного моделирования
Это процесс создания, управления и хранения информации об объекте капитального строительства на всех этапах его жизненного цикла (см. п.2.3 ГОСТ Р 10.0.01-2018).
По сути, ТИМ – российский аналог привычного многим BIM, т.е. технология создания ИМ ОКС.
Термин «ТИМ» пока не закреплён ни в одном нормативном документе; отсутствует он и в Градкодексе – закон содержит понятие «информационная модель».

ИМ ОКС — информационная модель объекта капитального строительства
Это уже юридическое понятие, закреплённое в п.10.3 ст.1 Градкодекса:

Информационная модель – это совокупность взаимосвязанных сведений, документов и материалов об объекте, которые формируются в электронном виде на этапах инженерных изысканий, проектирования, строительства, эксплуатации и сноса.

Важно понимать: ИМ ОКС – это не только 3D-модель. Это вся совокупность электронных данных об объекте, включая разнообразную документацию, результаты инженерных изысканий, атрибутивные данные и цифровую информационную модель (ЦИМ).

ЦИМ – цифровая информационная модель
ЦИМ – это виртуальный трёхмерный образ объекта или его части, собранный в один или несколько взаимосвязанных электронных документов в составе информационной модели.
Согласно п.3.1.4 СП 333.1325800.2020, это

совокупность взаимосвязанных инженерно-технических и инженерно-технологических данных об объекте капитального строительства, представленных в цифровом объектно-пространственном виде.

Проще говоря, именно ЦИМ – это тот самый файл (или несколько) с геометрией объекта и его атрибутами.
—
Запомнить за 30 секунд:
ТИМ – технология (процесс) создания ИМ.
ИМ – весь комплект цифровых данных об объекте.
ЦИМ – трёхмерная модель, входящая в состав ИМ.
—
В одной из следующих публикаций разберёмся с ответом на вопрос голосования – когда заказчик обязан требовать ИМ, а когда – ЦИМ, и что об этом говорят нормативные документы.
#разъяснения