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