Я хочу рассказать про то, как мы продолжаем убивать бумажный документооборот. Одна из областей, которая сдалась совсем недавно, — это технический документооборот, то есть все бумаги, которые нужны в процессе проектирования, строительства и других стадий жизненного цикла любого объекта. Давайте представим, что вам нужно построить башню. Это примерно то же самое, что строить Тёмную башню, но куда мрачнее по уровню бюрократии.
У такого строительства — даже если это Тёмная башня — есть чёткий (но довольно большой и сложный) процесс. Одни документы перетекают в другие, например, начинается всё с инженерных изысканий, потом появляется эскиз, потом сам проект, разрешения, вот уже сметы, служебные записки с замечаниями про то, что бак нашей башни не так отштукатурили и так далее. И в конце — регламенты и инструкции по эксплуатации.
Итак, башни еще нет, а документооборот уже есть, и он появляется задолго до строительства. Но уже с этапа возникновения идеи башни может использоваться наша система технического документооборота.
Начинается всё с задания на проектирование нового объекта. Предположим, вы решили построить эту самую башню на Красной площади. Может быть, оно очень правильно с точки зрения логики переходов между мирами, но, скорее всего, крайне нерационально экономически, да и по согласованиям имеет все шансы не пройти.
Поэтому первый этап — это оценка того, насколько вообще имеет смысл делать данный проект на текущем месте, и оправдают ли себя вложенные инвестиции.
Заказчик ставит задачу проектировщикам: мол, друзья, вот есть идея построить такой-то объект, возможно договориться строить его на таком-то месте. Расскажите, можно ли строить, и если да — сколько будет стоить.
Чтобы это сделать, нужно собрать кучу документов. В случае нашей башни понадобятся данные геологоразведки, план коммуникаций на участке, документы, регламентирующие строительство подобных башен и принципы использования нашей территории, тип земли и т.п. в соответствии с госстандартами и нормативно-правовой базой области, региона, где планируется строительство.
Перечень довольно большой.
Кроме того, что нужно собрать все разрешительные документы, нужно сделать еще и финансовый расчёт того, что будет строиться: сколько будет стоить строительство нашей башни в этом месте, и рентабелен ли будет такой проект. Это называется обоснованием инвестиций: пока оно довольно приблизительное, но даёт представление о том, стоит вообще браться за проект, или конкретно он и конкретно в этом месте абсолютно не оправдан.
После этого принимается решение, строить или нет.
Если решили строить — заказывается проектная документация, до этого всё было на уровне эскизов. Эскизы можно делать как угодно, хоть на салфетке карандашом в духе импрессионизма, главное, чтобы те, кто принимают решение о строительстве, поняли и кивнули.
Вообще, проектная документация — это тот еще геморрой. Это сложные системы взаимосвязи документов, горы папок с печатями и штампами. Разрешительные документы, которые формируют внешние органы, все еще остаются в бумажном виде, но наша софтина уже очень помогает на стадии проекта. Мы разработали систему технического документооборота КРОК СТДО специально для минимизации бумаги. Вы просто открываете программу, щёлкаете в «Создать проект: Тёмная башня, тип А» — и получаете полную структуру проектной документации, которая соответствует требованиям ФЗ. Там есть всё, что нужно по нормативам и законодательству для строительства именно таких объектов. Но, судя по ГОСТам, конечно, получится водонапорная башня. Тёмная — это пользовательское название.
Тут важно отметить, что универсальной схемы нет — у каждого типа объектов своя специфика. Но СТДО настраивается под нужды конкретного заказчика, что сильно упрощает ему жизнь.
Дальше надо загружать документы в систему и заполнять шаг за шагом вот эту здоровенную структуру проектной документации (кстати, план формирования пакета документов будет отражен в системе календарного планирования):
Данная структура поможет нам правильно собрать пакет документов для Главэкспертизы. Дело в том, что в строительстве башни есть важный переломный момент, когда вы собираете тонну бумаги и несёте её (нужно несколько человек, а для больших объектов — несколько огромных ящиков, либо огромный информационный носитель на десятки гигабайт) в госорган, который всё рассматривает и разрешает или не разрешает строить.
Если будет пропущена бумажка — госорган не скомпилирует всё и выкинет вас с эксепшном. Поэтому:
Это первая причина, по которой нужна автоматизированная система документооборота: когда нужно будет сдавать документы на экспертизу, они все будут на месте. Процесс их разработки можно распланировать и оценить в сроках. Видно, что конкретно сделано, что конкретно не сделано, у кого и где какая бумажка в работе, и какой статус. Это просто невероятное счастье для тех, кто хотя бы раз пробовал делать это в бумаге, а не в электронном виде.
Вот, смотрите, как один из кураторов строительства видит процесс и статус разработки отдельных разделов документа в процессе его подготовки:
На стадии подготовки пакета документов часто больше всего обсуждений между участниками проектирования, в процессе которых формируются замечания к документам, рождаются новые версии или ответы на выданные замечания. Вот так это выглядит и вот так можно сделать срез по всем замечаниям (или отфильтровать их, чтобы оценить объёмы доработок и посмотреть всю историю правок):
А вот это вид глазами одного из архитекторов — главная страница системы с трекером. Как видите, на нём висит несколько задач.
Также в системе можно вести и смотреть комментарии по документам в режиме переписки коллег. Вот тёплый ламповый чатик, в котором уже на кого-то переводят стрелки:
А это вид глазами подрядчика, который не работает в системе постоянно и не видит всего объёма как архитектор, но ему автоматически ставятся задачи и предоставляется доступ к нужным документам:
Проектная документация — это верхнеуровневое описание. Там нет деталей до конкретных лампочек, дверных ручек и так далее. Те же двери — это абстрактные двери, окна — абстрактные окна, стены — ну, просто стены и так далее. На уровне рабочей документации же, по которой будут строить наш объект, уже нужны детали. Например, как подводится вода, где электричество включается, как идёт кабель, тут — кран, тут — выключатель. По итогам каждого такого детализированного плана появляется смета на каждую часть объекта строительства.
Уже смета и комплект рабочих чертежей выдаются строителям. Они по этим документам строят, и они же по ним косячат. Потом их же тыкают в эту документацию и организуют приёмку работ. В реальном мире иногда нужно отступать от рабочей документации по объективным причинам, но не сильно далеко. Естественно, все изменения, включая изменения смет, учитываются в системе.
Любое изменение в одном документе по цепочке взаимосвязей прокидывается во все остальные документы и формируется в задачи на проверку этих документов. То есть, допустим, у нас как часть объекта строительства есть резервная дизельная электростанция, которая обеспечит электричеством наш объект в экстренном случае. Для строительства этой резервной дизельной электростанции готовится комплект рабочей документации, которая состоит из чертежей (например, армирование стен, кровельные перекрытия и др.), и смет на выполнение работ по этим чертежам. И если в чертеже для армирования стен у нас была сетка из металла, но по каким-то причинам ее меняют на сетку из стекловолокна, то должен быть произведен перерасчет сметы — система об этом напоминает, т.к. это документы одного комплекта. Причем ответственный за внесение правок сотрудник и его коллеги видят дедлайн внесения правок и имя ответственного.
Крутая фишка, которая есть в таком документообороте, — это просмотр чертежей прямо на месте, в браузере. Нам было это очень просто сделать, потому что на дворе уже двадцать первый век, и мы умеем конвертировать разные форматы в картинки. А вот для архитекторов это оказалось киллер-фичей, экономящей очень много времени:
Параллельно по строящемуся объекту приходят другие виды документов на системы и оборудование, которые используются в нашем объекте. Эти документы тоже заносятся в систему с привязкой к системе или конкретному оборудованию: паспорта, техусловия, программы испытаний и так далее:
В итоге объект оказывается достроенным, и вы получаете полный комплект документации на него сразу. Потому что любая бумажка правильно учитывалась и прикреплялась.
Конечный вид документов после пусконаладки — исполнительная документация. Это — то, как реально построен объект. В нашей Тёмной башне всё хорошо, и архитекторы герои. Но на других, не таких великих башнях, как наша, бывает разное. Вот был случай, на чертеже перила дверь перекрыли. В другом месте мостик перекинули. Там окно сдвинули.
На всё нужны приёмочные акты от разных комиссий. Комиссии смотрят, чтобы всё было по нормативу и не сильно далеко отходило от проекта, по которому дали разрешение на строительство. Например, кабели проложили не так — это нормально. А если вместо башни получился десяток коттеджей, соединённых подземными туннелями, — то заключения не будет. И придётся всё сносить. Примеры есть в Сочи, где сносят построенный жилой дом на берегу реки, в разных городах есть примеры с демонтажами верхних этажей небоскрёбов (когда согласовали 30, а получилось почему-то 33 или 48) и так далее.
Дальше надо провести испытания нашей башни. Испытываются как отдельные системы и оборудование по собственной программе, так и их комплексное взаимодействие. Если башня обеспечивает нормальное открытие перехода между мирами (простите, напор воды) и укладывается в нормативы, то всё в порядке.
В пусконаладке есть свой график работ, аналогичные согласования программ, формируются отчетные документы — все эти процессы учтены в СТДО.
Исполнительная документация передаётся в эксплуатацию. Чтобы началась работа на построенном объекте, нужны нормативные и эксплуатационные документы. Они также согласовываются и утверждаются, но другими людьми, не имеющими отношения к строительству. Тем не менее, в СТДО такой функционал тоже есть.
Документы, по которым ведется эксплуатация, периодически изменяются, а также имеют сроки пересмотра (когда ответственный за документ должен проверить, что все изменения внесены в документ корректно). О внесённых изменениях, замене или аннулировании документа рассылаются уведомления сотрудникам, которые в рамках своей работы должны руководствоваться данным нормативным или эксплу��тационным документом. Обычно за пару месяцев до приближения даты истечения срока пересмотра уведомление отправляется ответственному сотруднику, который отвечает за актуальность документа. Выглядит это вот так:
Даже у смотрителя Тёмной башни в СТДО есть рабочее место, где он видит все свои документы, сканы оригиналов, все правки и обсуждения, историю изменения документов, сроки документации и конкретные свои задачи.
Ещё система умеет рассылать уведомления и интегрируется с почтой — то есть не даст пропустить важные изменения и сроки, как бы вам того ни хотелось.
Большинство ведущих производителей ПО для проектирования так или иначе предлагали часть этих функций в своих пакетах. Но их решения в большинстве своём отстают от реалий того, что нужно на объектах, и от наших российских реалий тоже. Специализированный софт более зрелый и готовый.
Вот так проектируются, строятся, а потом эксплуатируются тёмные башни в нашей почти цифровой стране.
• Архитектурная 3D-съёмка
• BIM-системы
• Моя почта: ecm@croc.ru
У такого строительства — даже если это Тёмная башня — есть чёткий (но довольно большой и сложный) процесс. Одни документы перетекают в другие, например, начинается всё с инженерных изысканий, потом появляется эскиз, потом сам проект, разрешения, вот уже сметы, служебные записки с замечаниями про то, что бак нашей башни не так отштукатурили и так далее. И в конце — регламенты и инструкции по эксплуатации.
Итак, башни еще нет, а документооборот уже есть, и он появляется задолго до строительства. Но уже с этапа возникновения идеи башни может использоваться наша система технического документооборота.
До строительства
Начинается всё с задания на проектирование нового объекта. Предположим, вы решили построить эту самую башню на Красной площади. Может быть, оно очень правильно с точки зрения логики переходов между мирами, но, скорее всего, крайне нерационально экономически, да и по согласованиям имеет все шансы не пройти.
Поэтому первый этап — это оценка того, насколько вообще имеет смысл делать данный проект на текущем месте, и оправдают ли себя вложенные инвестиции.
Заказчик ставит задачу проектировщикам: мол, друзья, вот есть идея построить такой-то объект, возможно договориться строить его на таком-то месте. Расскажите, можно ли строить, и если да — сколько будет стоить.
Чтобы это сделать, нужно собрать кучу документов. В случае нашей башни понадобятся данные геологоразведки, план коммуникаций на участке, документы, регламентирующие строительство подобных башен и принципы использования нашей территории, тип земли и т.п. в соответствии с госстандартами и нормативно-правовой базой области, региона, где планируется строительство.
Перечень довольно большой.
Кроме того, что нужно собрать все разрешительные документы, нужно сделать еще и финансовый расчёт того, что будет строиться: сколько будет стоить строительство нашей башни в этом месте, и рентабелен ли будет такой проект. Это называется обоснованием инвестиций: пока оно довольно приблизительное, но даёт представление о том, стоит вообще браться за проект, или конкретно он и конкретно в этом месте абсолютно не оправдан.
После этого принимается решение, строить или нет.
Если решили строить — заказывается проектная документация, до этого всё было на уровне эскизов. Эскизы можно делать как угодно, хоть на салфетке карандашом в духе импрессионизма, главное, чтобы те, кто принимают решение о строительстве, поняли и кивнули.
Вообще, проектная документация — это тот еще геморрой. Это сложные системы взаимосвязи документов, горы папок с печатями и штампами. Разрешительные документы, которые формируют внешние органы, все еще остаются в бумажном виде, но наша софтина уже очень помогает на стадии проекта. Мы разработали систему технического документооборота КРОК СТДО специально для минимизации бумаги. Вы просто открываете программу, щёлкаете в «Создать проект: Тёмная башня, тип А» — и получаете полную структуру проектной документации, которая соответствует требованиям ФЗ. Там есть всё, что нужно по нормативам и законодательству для строительства именно таких объектов. Но, судя по ГОСТам, конечно, получится водонапорная башня. Тёмная — это пользовательское название.
Тут важно отметить, что универсальной схемы нет — у каждого типа объектов своя специфика. Но СТДО настраивается под нужды конкретного заказчика, что сильно упрощает ему жизнь.
Дальше надо загружать документы в систему и заполнять шаг за шагом вот эту здоровенную структуру проектной документации (кстати, план формирования пакета документов будет отражен в системе календарного планирования):
Данная структура поможет нам правильно собрать пакет документов для Главэкспертизы. Дело в том, что в строительстве башни есть важный переломный момент, когда вы собираете тонну бумаги и несёте её (нужно несколько человек, а для больших объектов — несколько огромных ящиков, либо огромный информационный носитель на десятки гигабайт) в госорган, который всё рассматривает и разрешает или не разрешает строить.
Если будет пропущена бумажка — госорган не скомпилирует всё и выкинет вас с эксепшном. Поэтому:
- Важно ничего не пропустить. Заполнить каждый раздел в структуре документа, чтобы не пришлось потом его обрабатывать в следующий раз.
- Важно не пренебрегать возможностью автоматического создания структуры документа, чтобы каждая бумажка из неё была не только учтена, но и поручена для разработки исполнителю, а потом согласована ответственными сотрудниками.
- Важно понимать, что если какая-то одна бумажка обновилась, то её обновление может потянуть за собой изменения в других бумажках, и если не отслеживать все взаимосвязи, то может начаться хаос.
Это первая причина, по которой нужна автоматизированная система документооборота: когда нужно будет сдавать документы на экспертизу, они все будут на месте. Процесс их разработки можно распланировать и оценить в сроках. Видно, что конкретно сделано, что конкретно не сделано, у кого и где какая бумажка в работе, и какой статус. Это просто невероятное счастье для тех, кто хотя бы раз пробовал делать это в бумаге, а не в электронном виде.
Вот, смотрите, как один из кураторов строительства видит процесс и статус разработки отдельных разделов документа в процессе его подготовки:
На стадии подготовки пакета документов часто больше всего обсуждений между участниками проектирования, в процессе которых формируются замечания к документам, рождаются новые версии или ответы на выданные замечания. Вот так это выглядит и вот так можно сделать срез по всем замечаниям (или отфильтровать их, чтобы оценить объёмы доработок и посмотреть всю историю правок):
А вот это вид глазами одного из архитекторов — главная страница системы с трекером. Как видите, на нём висит несколько задач.
Также в системе можно вести и смотреть комментарии по документам в режиме переписки коллег. Вот тёплый ламповый чатик, в котором уже на кого-то переводят стрелки:
А это вид глазами подрядчика, который не работает в системе постоянно и не видит всего объёма как архитектор, но ему автоматически ставятся задачи и предоставляется доступ к нужным документам:
Во время строительства
Проектная документация — это верхнеуровневое описание. Там нет деталей до конкретных лампочек, дверных ручек и так далее. Те же двери — это абстрактные двери, окна — абстрактные окна, стены — ну, просто стены и так далее. На уровне рабочей документации же, по которой будут строить наш объект, уже нужны детали. Например, как подводится вода, где электричество включается, как идёт кабель, тут — кран, тут — выключатель. По итогам каждого такого детализированного плана появляется смета на каждую часть объекта строительства.
Уже смета и комплект рабочих чертежей выдаются строителям. Они по этим документам строят, и они же по ним косячат. Потом их же тыкают в эту документацию и организуют приёмку работ. В реальном мире иногда нужно отступать от рабочей документации по объективным причинам, но не сильно далеко. Естественно, все изменения, включая изменения смет, учитываются в системе.
Любое изменение в одном документе по цепочке взаимосвязей прокидывается во все остальные документы и формируется в задачи на проверку этих документов. То есть, допустим, у нас как часть объекта строительства есть резервная дизельная электростанция, которая обеспечит электричеством наш объект в экстренном случае. Для строительства этой резервной дизельной электростанции готовится комплект рабочей документации, которая состоит из чертежей (например, армирование стен, кровельные перекрытия и др.), и смет на выполнение работ по этим чертежам. И если в чертеже для армирования стен у нас была сетка из металла, но по каким-то причинам ее меняют на сетку из стекловолокна, то должен быть произведен перерасчет сметы — система об этом напоминает, т.к. это документы одного комплекта. Причем ответственный за внесение правок сотрудник и его коллеги видят дедлайн внесения правок и имя ответственного.
Крутая фишка, которая есть в таком документообороте, — это просмотр чертежей прямо на месте, в браузере. Нам было это очень просто сделать, потому что на дворе уже двадцать первый век, и мы умеем конвертировать разные форматы в картинки. А вот для архитекторов это оказалось киллер-фичей, экономящей очень много времени:
Параллельно по строящемуся объекту приходят другие виды документов на системы и оборудование, которые используются в нашем объекте. Эти документы тоже заносятся в систему с привязкой к системе или конкретному оборудованию: паспорта, техусловия, программы испытаний и так далее:
В итоге объект оказывается достроенным, и вы получаете полный комплект документации на него сразу. Потому что любая бумажка правильно учитывалась и прикреплялась.
Конечный вид документов после пусконаладки — исполнительная документация. Это — то, как реально построен объект. В нашей Тёмной башне всё хорошо, и архитекторы герои. Но на других, не таких великих башнях, как наша, бывает разное. Вот был случай, на чертеже перила дверь перекрыли. В другом месте мостик перекинули. Там окно сдвинули.
На всё нужны приёмочные акты от разных комиссий. Комиссии смотрят, чтобы всё было по нормативу и не сильно далеко отходило от проекта, по которому дали разрешение на строительство. Например, кабели проложили не так — это нормально. А если вместо башни получился десяток коттеджей, соединённых подземными туннелями, — то заключения не будет. И придётся всё сносить. Примеры есть в Сочи, где сносят построенный жилой дом на берегу реки, в разных городах есть примеры с демонтажами верхних этажей небоскрёбов (когда согласовали 30, а получилось почему-то 33 или 48) и так далее.
Пусконакладка
Дальше надо провести испытания нашей башни. Испытываются как отдельные системы и оборудование по собственной программе, так и их комплексное взаимодействие. Если башня обеспечивает нормальное открытие перехода между мирами (простите, напор воды) и укладывается в нормативы, то всё в порядке.
В пусконаладке есть свой график работ, аналогичные согласования программ, формируются отчетные документы — все эти процессы учтены в СТДО.
Эксплуатация
Исполнительная документация передаётся в эксплуатацию. Чтобы началась работа на построенном объекте, нужны нормативные и эксплуатационные документы. Они также согласовываются и утверждаются, но другими людьми, не имеющими отношения к строительству. Тем не менее, в СТДО такой функционал тоже есть.
Документы, по которым ведется эксплуатация, периодически изменяются, а также имеют сроки пересмотра (когда ответственный за документ должен проверить, что все изменения внесены в документ корректно). О внесённых изменениях, замене или аннулировании документа рассылаются уведомления сотрудникам, которые в рамках своей работы должны руководствоваться данным нормативным или эксплу��тационным документом. Обычно за пару месяцев до приближения даты истечения срока пересмотра уведомление отправляется ответственному сотруднику, который отвечает за актуальность документа. Выглядит это вот так:
Что важно для тех, кто ведёт документацию?
Даже у смотрителя Тёмной башни в СТДО есть рабочее место, где он видит все свои документы, сканы оригиналов, все правки и обсуждения, историю изменения документов, сроки документации и конкретные свои задачи.
Ещё система умеет рассылать уведомления и интегрируется с почтой — то есть не даст пропустить важные изменения и сроки, как бы вам того ни хотелось.
- Интерфейс. Разработка чертежей ведется в профессиональных и многофункциональных «рисовалках». А облегчённый формат, который мы использовали в СТДО, позволяет удобно согласовывать эти чертежи, вести изменения, отслеживая актуальную версию. Киллер-фича — работа с чертежами из браузера (ревью чертежа без Автокада и Архикада).
- Обмен информацией с подрядчиками. Это важно. Под это делаются порталы у разных вендоров по такому софту. Одна поставка одной версии документов может занимать несколько DVD. Это технически сложно загружать-передавать, загружать долго, загрузка может прерваться. А так в разы легче.
- Автоматическое формирование структуры проектной документации.
- Автоматическое создание карточек документов на основе шаблонных описей документов (в формате Excel или Word). После загрузки данные из такой описи разберутся на карточки документов в системе — будут заполнены атрибуты, карточки будут размещены в нужной структуре, а также будут привязаны файлы (для этого файлы должны быть размещены в специальной сетевой папке, к которой у системы есть доступ). Это сокращает неудобства или затраты на обмен.
- Наличие цепочки связей между документами разных видов: проектной — рабочей — исполнительной, связь их с пусконаладочной, заводской документацией. Также в системе можно выбрать какие-либо оборудование (например, насос) и подобрать все документы, в которых он фигурирует: чертеж, его паспорт, технические условия, спецификацию, ремонтную документацию и др.
- Хранение в едином месте всех видов и всего объема документации, которая будет передаваться на экспертизу во внешние инстанции, а также использоваться при эксплуатации объекта.
- Просмотр всех версий документов, перечня замечаний и ответов на них.
- Обновление всей документации вовремя и по цепочке взаимозависимостей.
- У каждого задействованного в процессе работы с документом пользователя всегда в работе актуальная версия с возможностью просмотра предыдущих итераций.
Большинство ведущих производителей ПО для проектирования так или иначе предлагали часть этих функций в своих пакетах. Но их решения в большинстве своём отстают от реалий того, что нужно на объектах, и от наших российских реалий тоже. Специализированный софт более зрелый и готовый.
Вот так проектируются, строятся, а потом эксплуатируются тёмные башни в нашей почти цифровой стране.
Ссылки
• Архитектурная 3D-съёмка
• BIM-системы
• Моя почта: ecm@croc.ru
