Сетевые папки, облачные диски и электронная почта остаются привычными инструментами организации проектной документации. Для небольшого коллектива и относительно простого проекта этого зачастую достаточно. Проблемы становятся заметны с ростом числа участников, документов и изменений.

Для ГИПа это оборачивается вполне практическими сложностями: один документ существует в нескольких редакциях с именами «Финал», «Финал_2», «Исправленный», актуальный файл приходится искать среди папок и писем. Замечания заказчика находятся в переписке и на скриншотах, а после очередной выдачи не всегда удается быстро установить, какая именно редакция была передана. Появляются отдельные папки «На согласование», «Выдано», «Старое», которые фактически начинают выполнять роль статусов документа.

К этому моменту проблема заключается уже не в месте хранения файлов. Проекту требуется управление их состоянием: версиями, замечаниями, согласованиями, доступом и передачей документации. Эту задачу решает переход к среде общих данных (СОД).

Почему nano360

При переходе к СОД важно учесть не только наличие необходимых функций, но и сложность организационных изменений. Чем сильнее новая система отличается от привычного порядка работы, тем сложнее внедрение.

nano360 позволяет выполнить переход постепенно. Это облачное решение, поэтому для запуска не требуется разворачивать собственную серверную инфраструктуру. Проект при этом сохраняет привычную структуру файлов и папок. С файлами можно работать через веб-интерфейс, а nanoAgent обеспечивает работу с файлами напрямую, в проводнике Windows. Поэтому на начальном этапе пользователю необязательно полностью отказываться от привычной модели взаимодействия с файлами.

Другой особенностью nano360 является достаточно большая свобода организации проектного пространства. Она облегчает внедрение: не требуется сразу перестраивать все процессы под жестко заданную модель системы. Но эта же свобода связана с риском: два сотрудника могут решить одну задачу разными способами. Поэтому технический перенос необходимо дополнять организационными правилами.

Начните с анализа текущей работы

До создания структуры в СОД необходимо проанализировать, как сегодня организована работа с проектом. ГИПу следует определить, где фактически находятся рабочие данные: на файловом сервере, локальных компьютерах, облачных дисках или в почтовых вложениях. Затем посмотреть на структуру каталогов, наличие дубликатов и архивных копий, принципы именования файлов и существующий способ определения актуальной редакции.

Отдельно нужно проанализировать процессы вокруг документов: как выдается задание смежнику, как проверяется результат, где фиксируются замечания, каким образом документ отправляется на согласование, как формируется комплект для заказчика и принимаются изменения от подрядчика.

Цель такого анализа – не разработка большого регламента СОД, а получение двух практических результатов: целевой структуры проектных данных и перечня операций, которые после перехода должны выполняться единообразно.

На этом этапе полезно убрать очевидные недостатки существующего дерева папок. Однако полностью менять понятную команде структуру только ради внедрения СОД не требуется. Более того, сохранение знакомой логики размещения документации позволяет существенно упростить сам переход.

Важно, что этот анализ и подготовка структуры выполняются до дня перехода. К моменту переноса проекта уже должно быть понятно, где будут находиться документы и по каким основным правилам команда продолжит с ними работать.

Перенесите проект, а не начинайте его заново

После анализа подготовленную структуру можно создать в nano360. Если речь идет о значительном массиве данных, наиболее естественный сценарий – использовать nanoAgent: ГИП работает с проектом через проводник и переносит подготовленные папки и файлы привычным копированием. Это особенно удобно при миграции действующего проекта: пользователи получают знакомую иерархию разделов и комплектов, но дальнейшая работа уже происходит внутри СОД.

Архивные и текущие проекты требуют разного подхода. Для завершенных проектов достаточно определить состав сохраняемой документации и перенести архив. Для действующего проекта перед миграцией необходимо установить актуальное состояние документов. Не следует загружать в рабочую структуру все файлы АР.dwg, АР_новый.dwg, АР_итоговый.dwg и АР_итоговый_исправленный.dwg, рассчитывая разобраться с ними после перехода.

После миграции документ целесообразно вести уже как его версии. Предыдущие состояния сохраняются в истории, поэтому для них больше не требуется создавать копии файла и отдельные архивные каталоги.

Продолжите проект уже в СОД

Основной эффект проявляется не при загрузке данных, а когда команда начинает использовать возможности СОД в повседневных рабочих процессах.

Получив документ на проверку, ГИП может открыть его непосредственно в nano360. Просмотр *.dwg, DXF и IFC доступен без скачивания файлов и запуска САПР. Это удобно и при оперативном взаимодействии проектировщиков: для просмотра документа или решения вопроса не обязательно создавать еще одну локальную копию и передавать ее коллеге.

При проверке можно использовать графическую разметку непосредственно на документе. В nano360 доступны инструменты рисования и линий, текстовые пометки, выделение, рамки и области. Замечание оказывается связано с конкретным местом документа, а не существует отдельно в виде письма «См. правую нижнюю часть листа 7» или приложенного к нему скриншота.

При выпуске исправленной редакции полезно использовать сравнение версий, которое позволяет быстро определить, какие участки документа изменились. Для проектной документации целесообразно закрепить в правилах работы выпуск актуального PDF вместе с каждой новой редакцией чертежа. Сравнение доступно для PDF и поддерживаемых офисных форматов, тогда как *.dwg можно просматривать, но сравнение его редакций в nano360 не поддерживается.

После проверки документ может перейти к согласованию уже внутри СОД. Вместо последовательной рассылки вложений участникам запускается процесс параллельного согласования, в котором фиксируются участники, решения и состояние согласования.

Меняются и контакты с внешней стороной. Для взаимодействия с заказчиком или подрядчиком можно сформировать выборочный набор документов из разных частей проекта и предоставить его по публичной ссылке. Получателю для работы с такой ссылкой не требуется лицензия nano360. При публикации можно ограничить возможность скачивания документов, а также определить, какую версию файла будет видеть внешний участник. Это позволяет разделить внешний обмен и текущую работу проектировщиков.

Например, заказчику на согласование передается зафиксированная версия документа, в то время как проектировщик продолжает работу над следующей редакцией в nano360. Изменения рабочего файла в этом случае не меняют автоматически уже переданный на согласование материал. Если же задача состоит в постоянном предоставлении актуальной документации, ссылку можно настроить на отображение последней версии. Таким образом, публичная ссылка заменяет передачу независимых копий файлов и одновременно позволяет управлять тем, какое состояние документации доступно внешнему участнику.

Свободу работы необходимо закрепить правилами

Свобода организации работы в nano360 упрощает переход, но, как уже сказано, имеет и обратную сторону: одну и ту же задачу сотрудники могут решать разными способами. Чтобы такая свобода не привела к разнобою в работе с проектной информацией, основные процессы необходимо закрепить общими правилами. При этом нет необходимости регламентировать каждое действие пользователя – это лишь усложнит работу и повысит порог перехода.

Оптимальный подход – определить ограниченный набор процессов, где единообразие действительно важно: проверка и обработка замечаний, согласование, выпуск новой версии документа, передача задания смежнику и выпуск документации.

Для каждого такого процесса достаточно определить, кто его начинает, с какими данными, какие основные действия выполняются, какой результат считается завершением и что происходит при основных развилках. Например, «проверка → есть замечания → исправление → повторная проверка» либо «проверка → замечаний нет → согласование».

При этом в регламенте полезно указывать не только требуемое действие, но и конкретный инструмент nano360, с помощью которого оно выполняется, дополняя основные шаги скриншотами интерфейса. Такой регламент одновременно становится краткой практической инструкцией: сотруднику не требуется заранее изучать весь функционал системы – он осваивает необходимые возможности непосредственно в ходе работы, следуя понятному сценарию. Это позволяет начать работу в nano360 без отдельного предварительного обучения.

Разрабатывать такие регламенты своими силами необязательно. В качестве отдельной услуги специалисты компании «Макссофт» предлагают готовый комплект регламентов для основных процессов работы в nano360 и адаптируют его под роли и порядок работы конкретного заказчика. Это позволяет существенно сократить подготовительный этап и быстрее перейти к работе по единым правилам.

Переход на практике

Для небольшого проекта значительную часть предварительной работы способен выполнить сам ГИП. К моменту перехода структура данных должна быть подготовлена, актуальные документы определены, а основные правила дальнейшей работы – зафиксированы.

После такой подготовки непосредственный переход можно провести за один день. Подготовленный массив рабочих данных переносится через nanoAgent в созданное проектное пространство, подключаются участники, после чего команда продолжает работу с проектом уже внутри nano360.

В этот день особенно важно сопровождать первые реальные операции пользователей и сразу корректировать отклонения от принятого порядка, который требует:

• создавать новую редакцию как версию документа, а не как соседний файл;

• использовать при проверке графические замечания;

• выполнять согласование средствами СОД;

• решать оперативные вопросы непосредственно в проектном пространстве, не создавая лишних локальных копий;

• формировать при выпуске измененных чертежей PDF, необходимый для сравнения редакций.

В течение первой недели такой контроль стоит сохранить, постепенно снижая его интенсивность. На этом этапе уже не требуется заново выстраивать процессы – задача ГИПа состоит в том, чтобы закрепить принятый порядок на реальной работе. Если сотрудники создают папки «Старые версии», возвращаются к замечаниям по почте или начинают обмениваться локальными копиями документов, следует вернуть работу к предусмотренному регламентом сценарию. Одновременно становятся заметны реальные неудобства, которые можно устранить точечной корректировкой правил.

Именно такой сценарий позволяет говорить о переходе за один день. Это не означает, что анализ исходных данных, подготовка структуры и правил также выполняются в течение этого дня – они предшествуют запуску. Под переходом понимается переключение подготовленного действующего проекта на nano360: перенос данных, подключение команды и начало полноценной работы в новой среде. Последующий контроль первой недели уже не является продолжением миграции, а помогает закрепить новый порядок в повседневной работе.

Таким образом, переход на nano360 можно представить простой последовательностью: заранее подготовить структуру и правила – переключить проект на СОД за один рабочий день – сопровождать команду в первую неделю до закрепления нового порядка. Такой подход позволяет внедрить СОД без остановки действующего проекта и без одномоментной перестройки привычной организации работы проектировщиков.

Автор: Иван Немков, руководитель проектов САПР компании «Макссофт».

Оцените nano360 в работе. В течение бесплатного 30-дневного пробного периода доступны все возможности продукта. Попробовать бесплатно