Муки интеллегента...


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

1.1. Концепция черчения с постепенным сползанием в 3D. Наиболее яркие представители этого течения компания Нанософт, со своей линейкой 2D продуктов, которые сейчас демонстрируют (и весьма успешно!) некий инженерный BIM, как форму миграции в объем. Опора на файлы.

1.2. Мы свой, отдельный мир построим: Autodesk Revit, Renga Software & etc. Создание масштабных комплексов, где сделано практически все и близко к идеалу. К какому именно, правда не уточняется, но это монолитные среды, где внутри движка соревнование между брендами идет за функциональность, удобство извращений, поддержку калькуляторов, да много ещё чего. Здесь уже «попахивает» какой-то базой данных, в специфическом формате, в которой есть много, но увы далеко не все. Выход за границы такой среды информации возможен, но мучителен: ну невозможно, на современном уровне развития ИТ туда воткнуть все: слишком многое имеет лишь бумажную ипостась и все время носит характер «вау-фактора» для любой модели BIM.

1.3. Гербарий. Да именно так: вталкивание широкого спектра небольших по размеру кусочков программного кода в одну коробочку сайт, где данные с условными ограничениями, но все-таки интероперабельны. Т.е. результаты расчета одного модулька можно подоткнуть в другой модуль, где будет ещё один расчетик, и наматывая круги по разным блокам, можно получить достаточно «длинную цепочку ДНК мыслительной деятельности». Концепция Warehouse, как некого универсального хранилища, в котором есть все кролики «в одной шляпе». Перебирая ручонками, можно по очереди доставать каждый раз нового кролика. Можно производить математические (и не очень) операции над каждым кроликом или над всеми сразу. Какое это имеет отношение к конечному результату или росту качества, лично я вообще не понимаю. Концепция файловой помойки, где есть все, только вот где конкретно то, что действительно нужно прямо сейчас, не понятно.

1.4. Владимир Малахов (СТГМ) исповедует вообще исполинскую идею неких BIM-операторов: то ли владельцев Warehouse-ов, то ли электронных нотариусов каждого чиха вокруг стройки, к которым все ходят на поклон за данными и алгоритмами обработки этих данных.

1.5. Мое личное, возможно ублюдочное мнение, заключается в концепции: давайте сначала насильно-законодательно переведем имеющийся информационный массив вокруг стройки в электронный вид через аккредитованных Минкомсвязи операторов ЮЗЭДО (юридически значимого электронного документооборота). Каждый фантик, каждую бумажульку, пусть даже в сканах, но она где-то должна быть надежно сохранена на будущее. Юридически это закрепим, финальной, окончательной бумажкой, по образу и подобию насаждения портала госзатупок. А потом будем нам этими помойками производить булевы операции сложения и вычитания тел. 90% толковища вокруг всей стройки сейчас это поиск расхождений в документах у всех участников процесса, иногда с привлечением прокурорских. Поверьте, тотальная оцифровка всех бумаг вокруг стройки даст эффект больший, чем любой BIM. Ни что не нервирует русского строителя больше, чем невозможность уйти от ответственности!



Во всех этих стройных теориях «практического пикапа» на уровне периферии сознания все время рефреном мелькают мифически звери – производители стройматериалов и элементов строительных конструкций. Давайте их обяжем рисовать семейства для Revit? Нет, пусть типоразмеры для Renga нагенерят в рамках импортозамещения? В России прямо здесь и сейчас на рынке FCMG идет тихая, но плотная революция: EDI & ЮЗЭДО. Ритейл уверенно шагает в сторону оцифровки (как для себя, так и для мытарей в мышиной форме) своих информационных потоков. Почему эта стройная концепция http://www.gs1ru.org/ ну никак не отражена в строительной отрасли? Начать то ведь можно с простых вещей: через операторов ЮЗЭДО принудить законодательно производителей стройматериалов на законодательном уровне отдавать атрибутивную информацию о своих изделиях, вкупе с уведомлением об отгрузке. Со временем можно и семейства их научить отдавать в каких-то закрытых форматах. Это ведь не только штрих-кодирование, это ведь и RFID-метки: автоинвентаризация на стройплощадке в любой момент (кроме сыпучих грузов и метизов). Чтобы было понимание: отправку этих файлов заверять ЭЦП, которой пользуются 96,2% компаний в стране для сдачи отчетов в налоговую, типа «наливай, да пей».



Учитывая эпохальный уровень конфликтов вокруг разных концепций, есть понимание, что на уровне регулятора тоже «единства мнений нет», как именно должна развиваться и в какую сторону точно двигаться вся автоматизация стройки. Формирование ячеек со своими комплектами интересов, как раз следствие отсутствия общей, внятной и жесткой концепции. В итоге мы наблюдаем многостраничные документы, класса «мы будем, мы должны, давайте вот так вот напишем в плане, что через несколько лет — это должно концептуально выглядеть так-то». И никто не хочет брать на себя ответственность. Отсюда ватность и компромиссность каждого документа, уж простите за прямолинейность. Спускать силы и время на шлифовку этих текстов задача красивая, но с достижением реального результата плохо комплиментарная.



2.       Что же надо прямо сейчас? Определить надо основную технологическую составляющую, с выбором какого-то базового сценария из первого пункта: 2D/комплексы/гербарии/операторы BIM/операторы ЮЗЭДО (EDI). Т.е. просто принять эту веселую историю, как данность «мы будем идти по во-он тому пути». Все остальное под это ляжет само и нормативную базу править придется минимально.

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

3.1. Буховские документы оседлал Минфин и ФНС, ФСС, ПФР, ФТС.

3.2. ЭЦП, удостоверяющие центры – Минкомсвязи, ФСБ.

3.3. СМЭВ, МЭДО –Ростелеком, ФСО.

Сделанные не по их стандартам электронные документы или факты информационного обмена во всех отраслях идут в шредер строем. Т.е. сладкие мечты о каком-то отраслевом IFC моментально исчезают, потому что на совете главных конструкторов 56 ФОИВ-ов утвержден базовый формат XML. Сотни миллионов налоговых деклараций, отчетов в пенсионный фонд, электронных счетов-фактур ежегодно бегают через операторов и портал СМЭВ, как раз в формате XML, для каждого типа документа есть валидатор (XSD-схема). Никто не умер, все работает: 6,4 миллиона компаний по всей стране уже тут. И когда под сенью Минстроя рождается очередной 728 приказ (PDF, XLS, DOC, TIFF, Jpeg), сразу встает вопрос, как это потом через СМЭВ отдавать-то? Опять терять время и деньги?

Нужно понимать, что гораздо ловчее цинично использовать «до сэбэ» имеющуюся законодательную базу, наработанные практики, готовую инфраструктуру из смежных отраслей/ведомств. Опять же, как классический пример – ИСОГД муниципалитетов/регионов, как финальная точка хранения то ли плоских бумаг, то ли BIM-моделей после прохождения через операторов ЮЗЭДО, что гарантирует избавление от мучительных позывов местных властей править что-то «под себя», после получения. А в стройке оставить специализированное законотворчество.



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

Комментариев нет

Технологии Blogger.