В ТК 505 стали обсуждать необходимость актуализации СП 333.
На форуме Нанософт «Сила платформы» выдалась возможность объяснить, почему данная инициатива без изменения подхода к написанию требований не возымеет успеха. И что нужно, чтобы поменять сложившуюся ситуацию.
1️⃣ Идти по пути создания универсальных обязательных государственных атрибутов в одном СП - тупиковый путь. Таких атрибутов не существует из-за огромного разнообразия видов ОКС.
И нужно будет либо четко определиться с видами ОКС, что сделает СП более конкретизированным и узконаправленным. Либо полностью исключать атрибутивный состав ввиду регулярно обновляющихся стандартов, из которых эти атрибуты извлекаются.
2️⃣ СП333, исходя из названия, должен описывать правила формирования ИМ ОКС, а не требования к ней. Требования отвечают на вопрос "что?" (должно быть в модели). Правила - на вопрос "как?".
Как и каким образом должны формироваться сведения, документы и материалы, входящие в ИМ ОКС описывается в ПП РФ 614 "О правилах формирования и ведения ИМ ОКС..."
Зачем тогда еще раз писать правила в СП, если они описаны в постановлении?
Так, есть риск получить смысловые коллизии с ПП РФ 614 либо фактический повтор положений.
Исходя из 1 и 2, напрашивается вывод, что нет смысла переписывать документ, актуализируя атрибутивный состав. И сегодня нужно писать не правила формирования ИМ ОКС и не требования к каждому документу/элементу/файлу.
Нужно поменять сам подход с "административно-требовательного" на методический и писать правила создания цифровых требований к ИМ ОКС, которыми будут пользоваться все.
В документе должно быть описано, как и каким образом требования должны быть созданы, как определяется их полнота исходя из целей заказчика, форма их представления, структура и схема данных.
Такой подход:
🔹 приведет к единообразию требований к элементам ИМ и ЦИМ, что поспособствует формализации таких требований в цифровую форму.
🔹 будет способствовать плавному и осмысленному переходу к созданию собственных требований заказчика.
🔹 создаст базис для дальнейшего перевода сложных нормативных требований в цифровой вид.
Все это реализуется на базе открытых стандартов IFC и IDS. И хотя подход еще достаточно молодой и не единственный, но уже сейчас в России и мире есть работающие IT-решения и есть пользователи, которые используют это на практике.
📢 @IFC_ru
👥 @IFC_club
На форуме Нанософт «Сила платформы» выдалась возможность объяснить, почему данная инициатива без изменения подхода к написанию требований не возымеет успеха. И что нужно, чтобы поменять сложившуюся ситуацию.
1️⃣ Идти по пути создания универсальных обязательных государственных атрибутов в одном СП - тупиковый путь. Таких атрибутов не существует из-за огромного разнообразия видов ОКС.
И нужно будет либо четко определиться с видами ОКС, что сделает СП более конкретизированным и узконаправленным. Либо полностью исключать атрибутивный состав ввиду регулярно обновляющихся стандартов, из которых эти атрибуты извлекаются.
2️⃣ СП333, исходя из названия, должен описывать правила формирования ИМ ОКС, а не требования к ней. Требования отвечают на вопрос "что?" (должно быть в модели). Правила - на вопрос "как?".
Как и каким образом должны формироваться сведения, документы и материалы, входящие в ИМ ОКС описывается в ПП РФ 614 "О правилах формирования и ведения ИМ ОКС..."
Зачем тогда еще раз писать правила в СП, если они описаны в постановлении?
Так, есть риск получить смысловые коллизии с ПП РФ 614 либо фактический повтор положений.
Исходя из 1 и 2, напрашивается вывод, что нет смысла переписывать документ, актуализируя атрибутивный состав. И сегодня нужно писать не правила формирования ИМ ОКС и не требования к каждому документу/элементу/файлу.
Нужно поменять сам подход с "административно-требовательного" на методический и писать правила создания цифровых требований к ИМ ОКС, которыми будут пользоваться все.
В документе должно быть описано, как и каким образом требования должны быть созданы, как определяется их полнота исходя из целей заказчика, форма их представления, структура и схема данных.
Такой подход:
🔹 приведет к единообразию требований к элементам ИМ и ЦИМ, что поспособствует формализации таких требований в цифровую форму.
🔹 будет способствовать плавному и осмысленному переходу к созданию собственных требований заказчика.
🔹 создаст базис для дальнейшего перевода сложных нормативных требований в цифровой вид.
Все это реализуется на базе открытых стандартов IFC и IDS. И хотя подход еще достаточно молодой и не единственный, но уже сейчас в России и мире есть работающие IT-решения и есть пользователи, которые используют это на практике.
📢 @IFC_ru
👥 @IFC_club