Всё, что вы описываете — задание ГИПа, разрешение, доступ к новой ревизии на основании ранее выпущенной — начинает работать после того, как документация выпущена и утверждена, а участок модели заблокирован. Этот порядок я не трогаю, он нужен. Но статья про другой отрезок — до первого утверждённого выпуска. Проектировщик ведёт модель в своём рабочем контуре — задания, статусы, проверки там есть, но для Разрешения в классическом смысле ещё нет выпущенной ревизии, к которой его можно привязать. А главные решения принимаются именно здесь: чем наполняются данные, как увязываются атрибуты и связи, почему модель дошла до выпуска именно такой. И оговорюсь про термины: речь у нас о промышленных капитальных объектах — заводах, установках. Грубо говоря, рабочий контур там — программы, в которых создаётся модель, плюс СОД, а выпуск и согласования — в документообороте. И какой инструмент ни возьми, версии отвечают на вопрос "что было", а не "почему так сделали".
Так что говорим мы про разные отрезки жизни проекта: вы — про то, что после утверждённого выпуска, я — про то, что до него. Оба отрезка нужно держать под контролем, просто инструменты у них разные.
Вот теперь мы добрались до сути расхождения, и это хорошо.
С регистрацией изменений по 21.101 никто не спорит — механизм рабочий, и там, где он честно ведётся, история выпущенной документации прослеживается. Но весь этот аппарат включается, когда изменение уже дошло до бумаги: поправили чертёж, переписали абзац в пояснительной записке, передвинули позицию на схеме — и всё это оформили. Статья же про то, что происходит раньше, до всякой регистрации: сегодня первоисточник — информационная модель, и чертёж, и схема, и записка выпускаются из неё как производные. И вопрос не в том, как зарегистрировать изменение листа, а в том, под чьим контролем сами данные модели — атрибуты, связи, версии — и откуда они вообще берутся. По сути, регистрация работает уже со следствием. Статья — про причину.
Так что ГОСТ мы с вами читаем одинаково, расходимся только в том, к какому слою его прикладывать. Спасибо за обстоятельный разбор
Спасибо, что прочитали так внимательно. Колючесть — это нормально, предметный спор полезнее вежливых кивков.
Про стандарты спорить не буду, потому что не с чем: ГОСТы, ISO 19650 и 15926, TQ/TD — это то, чем мы работаем каждый день, никакого открытия тут нет. Статья про другой слой: не чем заменить стандарты, а куда девается понимание, почему сделано именно так, когда проект сдан, команда разошлась, а объект ещё живёт. Грубо говоря, ПДД у всех одни, а ездят все по-разному — и разбираться приходится именно с ездой.
Про масштаб потерь по отрасли во многом соглашусь, но это тема для отдельного большого текста, а не для ветки комментариев. Ещё раз спасибо за время.
Подрядчик делает работу. Заказчик должен уметь её принять — это разные вещи. Если внутри нет людей, способных прочитать документацию и понять, что именно передано, заказчик не контролирует проект, а просто доверяет на слово. Если этого внутреннего контура нет, получается обратная история: заказчик платит не только за работу, но и незаметно покупает зависимость. Завтра захочет сменить подрядчика — а не сможет, потому что никто, кроме той команды, не понимает, как всё устроено.
Всё, что вы описываете — задание ГИПа, разрешение, доступ к новой ревизии на основании ранее выпущенной — начинает работать после того, как документация выпущена и утверждена, а участок модели заблокирован. Этот порядок я не трогаю, он нужен. Но статья про другой отрезок — до первого утверждённого выпуска. Проектировщик ведёт модель в своём рабочем контуре — задания, статусы, проверки там есть, но для Разрешения в классическом смысле ещё нет выпущенной ревизии, к которой его можно привязать. А главные решения принимаются именно здесь: чем наполняются данные, как увязываются атрибуты и связи, почему модель дошла до выпуска именно такой. И оговорюсь про термины: речь у нас о промышленных капитальных объектах — заводах, установках. Грубо говоря, рабочий контур там — программы, в которых создаётся модель, плюс СОД, а выпуск и согласования — в документообороте. И какой инструмент ни возьми, версии отвечают на вопрос "что было", а не "почему так сделали".
Так что говорим мы про разные отрезки жизни проекта: вы — про то, что после утверждённого выпуска, я — про то, что до него. Оба отрезка нужно держать под контролем, просто инструменты у них разные.
Вот теперь мы добрались до сути расхождения, и это хорошо.
С регистрацией изменений по 21.101 никто не спорит — механизм рабочий, и там, где он честно ведётся, история выпущенной документации прослеживается. Но весь этот аппарат включается, когда изменение уже дошло до бумаги: поправили чертёж, переписали абзац в пояснительной записке, передвинули позицию на схеме — и всё это оформили. Статья же про то, что происходит раньше, до всякой регистрации: сегодня первоисточник — информационная модель, и чертёж, и схема, и записка выпускаются из неё как производные. И вопрос не в том, как зарегистрировать изменение листа, а в том, под чьим контролем сами данные модели — атрибуты, связи, версии — и откуда они вообще берутся. По сути, регистрация работает уже со следствием. Статья — про причину.
Так что ГОСТ мы с вами читаем одинаково, расходимся только в том, к какому слою его прикладывать. Спасибо за обстоятельный разбор
Спасибо, что прочитали так внимательно. Колючесть — это нормально, предметный спор полезнее вежливых кивков.
Про стандарты спорить не буду, потому что не с чем: ГОСТы, ISO 19650 и 15926, TQ/TD — это то, чем мы работаем каждый день, никакого открытия тут нет. Статья про другой слой: не чем заменить стандарты, а куда девается понимание, почему сделано именно так, когда проект сдан, команда разошлась, а объект ещё живёт. Грубо говоря, ПДД у всех одни, а ездят все по-разному — и разбираться приходится именно с ездой.
Про масштаб потерь по отрасли во многом соглашусь, но это тема для отдельного большого текста, а не для ветки комментариев. Ещё раз спасибо за время.
Подрядчик делает работу. Заказчик должен уметь её принять — это разные вещи. Если внутри нет людей, способных прочитать документацию и понять, что именно передано, заказчик не контролирует проект, а просто доверяет на слово. Если этого внутреннего контура нет, получается обратная история: заказчик платит не только за работу, но и незаметно покупает зависимость. Завтра захочет сменить подрядчика — а не сможет, потому что никто, кроме той команды, не понимает, как всё устроено.
(del)