Plannerly

Plannerly — облачная платформа для управления BIM и проектной информацией в архитектуре, инженерии и строительстве. Она объединяет подготовку BIM Execution Plan и других управленческих документов, структурирование требований к информационным поставкам, распределение ответственности, календарное планирование, приемку файлов и автоматизированную проверку моделей. Основные рабочие области называются Docs, Scope, Verify и File Manager; рядом с ними используются Timeline, Kanban, роли, согласования, электронные подписи и отчётные панели. Plannerly не является CAD- или BIM-авторингом вроде Revit: геометрию здесь не моделируют, а определяют, какую информацию команда должна выпустить, кто отвечает за поставку, когда она требуется и соответствует ли полученный файл заданным критериям.

Что такое Plannerly и для каких задач она предназначена

Продукт относится к классу BIM management и information management. Его разработчик — LOD Planner, Inc. Историческое корпоративное название объясняет, почему в старых юридических материалах и ранних публикациях встречается LOD Planner, однако текущий продукт и интерфейс называются Plannerly. Сервис работает через браузер и поставляется как онлайн-приложение: отдельного публичного установщика Plannerly для Windows или macOS не требуется, поэтому размер локального дистрибутива к нему неприменим.

Главная практическая идея Plannerly — связать договорённости и фактическую выдачу информации. В типичном BIM-проекте BEP может жить в Word, матрица ответственности — в Excel, сроки — в отдельном графике, модели — в CDE, а замечания — в переписке. Plannerly переносит значительную часть этой цепочки в связанные сущности: документ описывает правила, Scope фиксирует ожидаемые deliverables и information requirements, Timeline задаёт сроки, File Manager хранит выдачу, а Verify сопоставляет модель с требованиями. За счёт связей изменение не обязательно переносить вручную в несколько файлов.

Целевая аудитория — BIM-менеджеры, information managers, BIM/VDC-координаторы, руководители цифрового проектирования, архитектурные и инженерные команды, генеральные подрядчики, владельцы объектов и консультанты, которым необходимо формализовать информационные требования и контролировать их исполнение. Для одиночного 3D-моделирования без договорного или координационного контура Plannerly избыточен: он раскрывается там, где есть несколько сторон, стадии, пакеты работ, правила выдачи и процедура проверки.

Поддержка ISO 19650 проходит через несколько уровней. В Docs имеются шаблоны и структура для BEP и связанных документов. Scope позволяет представлять требования не только текстом, но и как проверяемые поля, свойства, допустимые значения, единицы и привязку к этапу. File Manager может использоваться как common data environment с версиями, метаданными и состояниями файлов. Verify превращает часть требований в машинно проверяемые правила. При этом сама программа не заменяет знание стандарта: корректность терминологии, назначения ролей, контрактной схемы и критериев остаётся ответственностью проектной команды.

Чем Plannerly не является

Plannerly не создаёт стены, семейства, трассы инженерных систем или рабочие чертежи как авторинговые BIM-системы. Его 3D-просмотр и индексирование модели предназначены для контроля и связи с требованиями. Если задача состоит в редактировании исходной геометрии, изменение выполняется в Revit, IFC-ориентированном авторинге или другом исходном приложении, после чего новая версия публикуется и снова проверяется в Plannerly.

Сервис также не сводится к файловому облаку. File Manager действительно хранит документы и модели, но существенная часть продукта находится выше уровня хранения: формирование BEP, scope matrix, milestones, work packages, acceptance criteria, model checking и dashboards. Поэтому сравнивать Plannerly только по объёму диска с обычным облачным хранилищем некорректно.

Модель распространения, планы и лицензирование

Plannerly распространяется как SaaS. Для начала работы создаётся учётная запись в веб-приложении. В актуальной структуре планов присутствуют Free, Individual, Team и Enterprise. Тарифы могут оплачиваться ежемесячно или ежегодно; для годовых планов предусмотрена оплата по счёту, а среди поддерживаемых способов оплаты перечислены банковские карты и банковский перевод. Числовые цены в этом обзоре не фиксируются, потому что они меняются отдельно от возможностей приложения и для корпоративного уровня зависят от конфигурации заказа.

Free предназначен для знакомства с рабочим процессом и базовой работы. Individual ориентирован на одного специалиста. Team рассчитан на совместную проектную команду. Enterprise добавляет корпоративные механизмы, включая расширенное управление безопасностью и варианты размещения данных. На практике выбор тарифа следует привязывать не к названию компании, а к ролям, количеству редактирующих пользователей, числу проектов, требованиям к SSO, интеграциям и администрированию.

В Plannerly различаются пользователи, которые только просматривают информацию, и участники, меняющие проект. В материалах по ролям Viewers описаны как бесплатные пользователи для просмотра, тогда как Editors, Managers и другие роли, дающие право редактирования или управления, занимают платные места согласно плану. Это важно при расчёте лицензий: большое число согласующих или наблюдателей не означает автоматически такое же число полноценных редакторских лицензий.

Корпоративной команде до покупки полезно составить матрицу реальных действий. BIM-менеджеру могут потребоваться создание проектов, управление ролями, Docs и Scope; инженеру — редактирование назначенных требований и загрузка выдачи; заказчику — просмотр, комментарии и согласование; администратору — SSO и политика доступа. Такая матрица быстрее показывает, сколько платных мест действительно нужно, чем попытка лицензировать всех одинаково.

Отдельно существует учебная среда Plannerly. Учётная запись для курсов не совпадает с учётной записью основной платформы: одинаковый адрес электронной почты использовать можно, но регистрацию выполняют отдельно. Это различие объясняет часть проблем с входом, когда пользователь имеет профиль на training-сайте, но ещё не зарегистрирован в приложении.

Доступ, регистрация и первый запуск

Установка в привычном смысле отсутствует. Пользователь открывает веб-приложение, создаёт аккаунт и затем входит через браузер. Для платформы доступны вход по электронной почте и паролю, а также авторизация через Google, Microsoft/Azure, Autodesk, Procore, LinkedIn и Facebook. В корпоративной среде набор методов может быть ограничен политикой организации.

1. Создайте аккаунт приложения. Регистрация основной платформы выполняется отдельно от учебного портала. После регистрации пользователь попадает в рабочее пространство с аккаунтами и проектами.
2. Проверьте язык интерфейса. В профиле можно выбрать персональный язык приложения. Русский входит в опубликованный список интерфейсных языков. Язык проекта настраивается отдельно и влияет на проектные стандарты, шаблоны, библиотеки элементов и экспортируемые документы.
3. Создайте проект. В Projects workspace используется команда New Project или кнопка с плюсом. В дальнейшем проект открывает доступ к Docs, Scope, Verify и File Manager.
4. Назначьте роли до наполнения проекта. Если сначала открыть редактирование всем участникам, а затем ограничивать права, проще случайно оставить лишний доступ. Менеджеру целесообразно сначала определить Managers, Editors и Viewers, а затем приглашать команду.
5. Выберите первую рабочую область. Для BEP логично начать с Docs; для матрицы поставок — со Scope; для контроля уже существующей модели — с Verify; для централизованной работы с файлами — с File Manager.

При корпоративном входе Plannerly поддерживает Microsoft Entra ID. Администратор может зарегистрировать приложение в Entra, назначить разрешённых пользователей и затем запросить ограничение домена входом только через Microsoft. В таком режиме пароли Plannerly и альтернативные социальные методы для заданного домена блокируются. Для команды это не косметическая настройка: SSO следует согласовать до массового приглашения, чтобы сотрудники не создавали параллельные способы авторизации.

Интерфейс Plannerly: логика модулей и навигации

Интерфейс построен вокруг проекта. Слева располагаются рабочие области, а содержимое центральной части меняется в зависимости от выбранного модуля. В актуальных материалах постоянно фигурируют Docs, Scope, Verify и File Manager. Дополнительные представления Timeline и Kanban используются для сроков и статусов. В старых снимках интерфейса можно увидеть названия Plan и Exports; современная структура документации использует Docs и File Manager, поэтому при обучении по ранним роликам названия следует сопоставлять с текущими.

В Account Dashboard отображаются аккаунты и проекты. По проектам работает поиск по имени. Внутри проекта доступ зависит от роли: один участник может видеть документы и модель, но не иметь права менять требования; другой получает административные действия. Эта гранулярность особенно заметна в окне Manage Roles, где разрешения разделены по General, Docs, Scope, Verify и File Manager.

Окно SmartFields показывает типы динамических полей, поиск, фильтрацию и их использование в документах.

SmartFields нужны для данных, которые повторяются в нескольких местах: названия проекта, дат, этапов, команд и других параметров. Вместо ручного исправления каждого абзаца документ ссылается на поле. В обновлении от 10 апреля 2026 года появились поиск, фильтр по типу и сортировка или группировка SmartFields, что особенно заметно в больших шаблонах.

Разрешения как часть интерфейса

Окно Manage Roles не ограничивается общей галочкой «редактор». Разрешения распределяются по операциям: доступ к модулю, управление документами, SmartFields, секциями, Scope, milestones, information requirements, Verify, моделями и File Manager. Это позволяет дать участнику доступ к просмотру модели без права менять правила проверки либо разрешить работу с назначенными разделами документа без полного администрирования проекта.

Практический вывод из такой модели доступа — права лучше проектировать по функциям, а не по должностям. Два инженера с одинаковой должностью могут иметь разные задачи: один только загружает документы в placeholders, второй формирует information requirements. Ролевой профиль должен отражать именно набор действий.

Docs: документы, BEP, согласование и автоматизация

Docs — редактор структурированных проектных документов. В нём создают BEP, информационные планы, договорные приложения, требования заказчика и другие тексты, которые должны совместно редактироваться и проходить согласование. Документ разбивается на секции; секции можно добавлять вручную или брать из шаблона. Для BEP рабочая последовательность начинается с открытия проекта, перехода в Docs и выбора Use Template либо добавления секций через + Add a Section.

Шаблон не является неизменяемым файлом. После вставки пользователь редактирует текст секций, меняет их порядок перетаскиванием, добавляет изображения, ссылки и checklists, назначает участников и настраивает согласование. Такая организация удобна, когда BEP должен развиваться вместе с проектом, а не существовать как PDF, который пересоздают после каждого замечания.

Библиотека Docs открывается значком Library. В выпадающем списке доступен набор Plannerly Templates, в том числе материалы, построенные вокруг ISO 19650. Проектная команда может изменить вставленный шаблон под собственные правила. Шаблоны Scope устроены отдельно: там хранятся классификации и information requirements, а также используется buildingSMART Data Dictionary.

Секции и состояния документа

Рабочей единицей Docs является секция. У секции есть содержимое, участники, состояние и действия через меню. Разделение на секции позволяет согласовывать документ частями: например, Project Information можно подготовить раньше, чем детальную матрицу ответственности. В больших BEP это сокращает конфликт редактирования и помогает видеть, какие фрагменты готовы, а какие ещё в работе.

Для макета доступны обычные средства форматирования текста и таблиц, а также Document View. Последний показывает границы страницы и ориентацию секции так, как они будут выглядеть при экспорте. У конкретной секции можно выбрать Change Portrait / Landscape. Ориентация меняется только для выбранной секции, поэтому широкую матрицу можно развернуть в альбомный вид, не меняя весь документ.

Вставленный из Word или другого редактора контент способен принести скрытые стили. Если таблица ведёт себя непредсказуемо или текст выглядит неоднородно, выделяют проблемный фрагмент, открывают More Text и выбирают Clear Formatting. После очистки применяются стили Plannerly. Для больших таблиц дополнительно уменьшают ширину колонок или размер шрифта и проверяют результат в Document View до экспорта.

SmartFields и ссылки между разделами

SmartFields заменяют повторяющиеся значения динамическими полями. В редакторе через Insert SmartField доступны Project SmartFields, System SmartFields и Section Reference. Project SmartFields содержат данные конкретного проекта; System SmartFields — системные значения, например даты экспорта и сведения о milestones; Section Reference вставляет ссылку на другую секцию документа. Это снижает риск, что один и тот же проектный параметр окажется разным в титульной части, BEP и приложении.

В окне Section Reference видна иерархия разделов документа. Ссылка остаётся связанной с целевой секцией, поэтому шаблон можно строить не как набор копий, а как сеть ссылок на уже определённые части. В февральском обновлении 2026 года механизм расширили: Smart Section References работают между шаблонами, проектами и экспортами, а PDF получает закладки для навигации по разделам.

При проектировании корпоративного шаблона имеет смысл сначала выделить значения, которые действительно должны быть едиными: название проекта, адрес, язык, стандарт, даты, названия команд и milestones. Их переносят в SmartFields. Уникальный пояснительный текст оставляют обычным содержимым. Если превращать каждую фразу в динамическое поле, шаблон становится сложнее поддерживать без выигрыша в согласованности.

Поиск и версия документа

В Docs есть важное ограничение: отдельного встроенного полнотекстового поиска по содержимому секций в текущей справке нет. Чтобы найти текст, сначала разворачивают все нужные секции, затем используют поиск браузера Ctrl+F в Windows или Command+F в macOS. Если секция свёрнута и её текст не отрисован, браузер не найдёт содержимое. В Scope ситуация другая — там имеется собственный поиск по строкам, кодам, типам и названиям information requirements.

Version History доступна Editors и Managers. После выбора значка Version History слева отображаются текущая и предыдущие версии. Режим No Comparison показывает выбранное состояние без подсветки. Compare to Previous выделяет добавленное зелёным, а удалённое красным. Compare to Current сопоставляет старую версию с текущей. Этот механизм удобен не для формального хранения «на всякий случай», а для конкретной проверки: что именно поменялось после совещания, какие формулировки исчезли и нужно ли восстановить прежний вариант.

Историю версий Docs нельзя путать с возможностью вернуть удалённую вкладку. Для полностью удалённого документа опубликованное правило жёстче: восстановление удалённой вкладки в Docs не предусмотрено. Если ранее был экспорт, содержимое можно реконструировать через Word: в File Manager у файла выбирают Create .docx, затем в Docs — Add New и Import Word Doc. Поэтому для критичных договорных документов полезны регулярные версии и экспорт, а не надежда на корзину.

Экспорт PDF и Word

Документы из Docs экспортируются в PDF и Word. При подготовке экспорта можно выбирать документы, фильтровать содержимое и настраивать оформление, шрифты, обложку, колонтитулы и другие элементы. Для Scope экспорт включает собственные представления, например Grid, Timeline, Details и Info, если они нужны в выдаче. В результате одна и та же структурированная база может давать разные документы для договора, внутренней проверки и отчёта.

Перед формированием PDF полезно проверять не только текст, но и геометрию страницы. Широкие таблицы чаще всего исправляются переводом конкретной секции в Landscape. Затем в Document View проверяют фактические границы. Если таблица всё ещё выходит за страницу, сокращают текст ячеек, ширину колонок или кегль и очищают импортированное форматирование. Такая последовательность быстрее случайных изменений всего документа.

Экспорт может стать версионируемым объектом File Manager. После первого формирования PDF в колонке Version появляется управление новой версией. В Auto Version Settings задаются частота — daily, weekly, monthly или custom interval, конкретные дни и время, а также необязательные получатели. Можно не отправлять письма и просто сохранять свежие версии в File Manager. Это удобно для регулярного отчёта, который строится из одних и тех же живых данных.

Live Dashboards

В обновлении 6 апреля 2026 года в Docs появились Live Dashboards. В документ добавляется chart block, после чего диаграмма получает данные из задач Verify. Доступны компоновки рядом или вертикально и фильтрация. 4 апреля добавили фильтры графиков по Work Package. Это превращает документ в отчёт, который можно читать в интерфейсе и затем автоматически выпускать в PDF по расписанию.

На снимке три диаграммы показывают разные пакеты работ и доли Missing, Incorrect и Correct. Практическая ценность не в самой круговой диаграмме, а в связи с Verify: BIM-менеджеру не требуется вручную переносить результаты проверки из модели в презентацию. Однако достоверность панели зависит от правил Verify и правильного назначения Work Packages. Ошибка в исходных требованиях автоматически сделает неверным и отчёт.

Scope: структурированные требования и ответственность

Scope — центральная область для превращения требований из текста и таблиц в проверяемую структуру. Слева находится иерархия папок; папки могут быть вложенными и образовывать work breakdown structure. Внутри расположены task rows. Строка задачи содержит название deliverable, classification code, subtitle и entity type. Через меню с тремя точками и Edit открывается task modal, где редактируются свойства задачи.

По горизонтали Scope строится вокруг milestones. Каждый столбец представляет этап или точку выдачи. Пересечение строки задачи и столбца milestone образует cell. Если в ячейке задана поставка, она описывает, что именно требуется от конкретной задачи к этому этапу; пустая ячейка означает отсутствие поставки на этой точке. Ячейка может содержать document placeholders, checklists и acceptance criteria.

Интерфейс Scope умеет работать с классификационными наборами и импортом структурированных требований. На показанном экране видны Uniclass folders and elements, Import Settings, а также команды IMPORT CSV и IMPORT IDS. IDS здесь особенно важен для openBIM: требования можно передать в машинно читаемой форме и использовать их как основу проверки модели в совместимых процессах.

Структура information requirement

Information requirement в Scope состоит не из одного текстового поля. Для требования определяются information group или property set, title, description, tags, verification rule, allowed values и units. Например, требование к свойству стены может быть связано с Pset_WallCommon, конкретным названием параметра, допустимым перечнем значений и единицей измерения. Такая детализация и делает автоматическую проверку возможной: Verify получает не абзац с пожеланием, а правило, которое можно сопоставить со свойством элемента.

Внизу интерфейса доступно управление project information requirements. Редактирование выполняется двойным щелчком или через Manage. При настройке проекта можно выбрать buildingSMART data dictionaries, по которым Scope ищет классификации и свойства. Это снижает число самодельных названий и помогает поддерживать одинаковую терминологию между командами.

View Preferences и пользовательские поля

Scope способен показывать много строк и параметров, поэтому представление настраивается через View Preferences — значок настроек над сеткой. Field row visibility переключает, какие категории видны непосредственно в grid. Среди вариантов есть Information Requirements, Checklists, Description и Documents. Для совещания по выдаче файлов можно оставить Documents, а для настройки качества модели — Information Requirements и Checklists.

Manage Task Fields добавляет собственные поля, которые появляются у задач проекта. Опубликованные типы включают Data, Text, Pick list и URL. Pick list полезен, когда нужно ограничить значения утверждённым набором; Text оставляют для свободного пояснения; Data — для числового значения; URL — для внешней ссылки. Пользовательские поля следует вводить централизованно, иначе похожая информация быстро расползается по нескольким полям с разными именами.

Document placeholders

Не каждый deliverable является 3D-моделью. Для чертежа, отчёта, ведомости, сертификата или спецификации задача может не иметь geometry. В ячейке milestone создаётся placeholder, который заранее описывает ожидаемый файл. В рабочем сценарии доступны drag and drop фактического файла, Add placeholder для будущей поставки, Add from existing files для связи с уже загруженным объектом File Manager и Add link для ссылки на внешнее расположение.

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

Work Packages

Work Package фильтрует Scope по ответственности команды. Выбор пакета оставляет в сетке только соответствующие deliverables. Тот же пакет используется в model checking: Verify можно направить на набор требований конкретной команды, не проверяя весь проект. Это особенно полезно при поэтапной выдаче, когда архитекторы и инженеры публикуют модели в разное время.

При создании Work Packages важно не превращать их в произвольные теги. Один пакет должен соответствовать понятной зоне ответственности или договорному пакету. Тогда его можно использовать последовательно в Scope, Verify и Dashboard. Если пакет означает одно в матрице, другое в фильтре и третье в отчёте, автоматизация теряет смысл.

Timeline и Kanban: сроки, зависимости и исполнители

После определения deliverables их можно перенести из матрицы в календарное представление. Timeline показывает задачи на временной шкале, а Kanban группирует работу по состояниям. Смысл этих представлений в том, что срок не существует отдельно от Scope: это та же задача, для которой уже определены deliverable, команда и критерии приёмки.

В полном workflow Plannerly дата задачи меняется перетаскиванием края полосы Timeline либо через календарь. Для длительности принимаются обычные записи вроде 10 days, 1.5 weeks и сокращённые варианты. Между задачами можно создать finish-to-start dependency: связь от окончания первой задачи к началу следующей заставляет зависимую задачу смещаться при изменении предшественника. Для назначения исполнителя задачу открывают из Timeline и выбирают участника; его avatar появляется на задаче.

Такая связка полезна только при дисциплине планирования. Если milestone в Scope обозначает контрактную дату, а Timeline содержит неактуальный внутренний график, команда получает две версии истины. До запуска проекта стоит решить, какие даты являются договорными, какие — рабочими, и кто имеет право их менять.

Этот снимок опубликован в 2023 году и показывает более раннюю навигацию с пунктами Plan, Scope, Verify и Exports. Само представление Timeline с полосами задач остаётся полезным для понимания принципа календарного планирования, но при работе с текущей версией ориентироваться нужно на современные названия модулей.

Verify: проверка модели по требованиям

Verify связывает Scope с фактической BIM-моделью. Сначала модель загружается или подключается из внешней среды, затем Plannerly индексирует элементы и свойства. После этого задачи Scope связываются с группами элементов, а verification rules проверяют свойства относительно information requirements. В результате пользователь видит не просто модель, а состояние соответствия: какие требования выполнены, отсутствуют или содержат неверные значения.

Поддержка модели не ограничена IFC. В описании платформы заявлено более 80 форматов, а в рабочих инструкциях прямо встречаются Revit/RVT, IFC, SketchUp, DWG, DWF и DWFx. Для конкретного проекта нужно различать два вопроса: способен ли Viewer открыть файл и способен ли Verify извлечь из него свойства, необходимые для правил. Проверка данных требует индексации.

На интерфейсном снимке Verify модель показана рядом с задачами и индикаторами состояния. Зелёная визуализация сама по себе не доказывает инженерную корректность элемента: она отражает состояние тех правил, которые действительно настроены. Поэтому первый контроль после создания проверки — убедиться, что выбран правильный набор элементов и что правило смотрит на нужное свойство.

Загрузка, Index и обработка модели

После загрузки модели Plannerly предлагает обработку. Индексирование извлекает элементы и их свойства, структурирует и подготавливает данные для поиска и автоматической проверки. Для просмотра 3D обработка не обязательна: без полного processing остаются навигация от первого лица, измерения, сечения, дерево модели и просмотр свойств. Автоматические rules и validation становятся доступны после обработки.

Для Revit-модели размером около 150 MB опубликованный ориентир обработки составляет примерно 5–20 минут. Диапазон широк, потому что размер файла не показывает число элементов и свойств: модель того же объёма может содержать сотни тысяч объектов и миллионы точек данных. Обработка идёт в фоне, а после её завершения пользователь получает уведомление по электронной почте.

Этот ориентир нельзя превращать в SLA для любого файла. При планировании регулярной выдачи разумнее закладывать processing как отдельный этап перед контрольным сроком, особенно для больших моделей. Если модель должна пройти acceptance check к 17:00, загружать её в 16:55 рискованно даже при хорошем соединении.

Связывание задач с элементами

В Verify сначала определяют, какие элементы модели относятся к задаче Scope. Для связи используются правила отбора: например, условие по имени, типу или другому доступному атрибуту. После linking система может проверить information requirements только на релевантной выборке. Проверка всех объектов одной и той же схемой без фильтра быстро приводит к ложным ошибкам.

Для сложного проекта полезно идти от малого к большому. Сначала связать одну хорошо понятную задачу с небольшой категорией, убедиться в составе элементов, затем проверить одно свойство. После подтверждения принципа масштабировать правила на весь Work Package. Такой порядок помогает отделить ошибку модели от ошибки конфигурации Plannerly.

Почему параметр не проверяется

Одна из наиболее частых проблем Verify — несовпадение названия параметра модели и information requirement. Сопоставление чувствительно даже к пробелам. Для проверки открывают property window модели, копируют имя параметра и ищут точное совпадение в Information Requirements. Затем выполняют обратную проверку: копируют имя требования и ищут его среди свойств модели. Это обнаруживает trailing spaces и визуально незаметные различия.

Второй источник ошибки — Property Set или группа. Если requirement требует свойство в конкретном Pset, одинаковое имя в другой группе не считается подходящим. Если группа не задана, Plannerly ищет совпадение шире. Поэтому исправление должно начинаться не с переименования модели наугад, а с проверки того, какую группу требует правило.

Третья причина связана с иерархией. По умолчанию Plannerly ищет свойства на нижнем уровне дерева элемента. В сборке параметр может храниться на родительском объекте: например, у составной двери свойство находится не на ручке или панели, а на родительской двери. В Task Link Settings открывают chain link для нужной связи и снимают Link Leaf Elements, чтобы разрешить поиск на более высоком уровне иерархии.

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

Опубликованные Revit views

При работе с Revit Plannerly использует опубликованные views. Если объект скрыт в опубликованном Revit view, он будет скрыт и в 3D Viewer Plannerly. Если нужного вида нет, сначала исправляют Published Settings в Revit, сохраняют или публикуют новую версию, затем обновляют модель. При подключении через ACC/BIM 360 новая версия может синхронизироваться автоматически.

Эта зависимость важна при разборе «пропавшей геометрии». Ошибка не обязательно находится в Plannerly. Сначала проверяют, был ли объект видим в исходном опубликованном представлении Revit. Только после этого ищут проблему в импорте или связи.

File Manager и использование Plannerly как CDE

File Manager собирает файлы проекта и связывает их с Docs, Scope и Verify. В него можно загружать PDF, изображения, Excel-файлы, Revit- и IFC-модели, контракты и отчёты. Файлы организуются папками и saved filters, получают metadata, naming conventions и version control. Это позволяет использовать Plannerly как common data environment, особенно когда команда хочет хранить не только файлы, но и контекст их создания и проверки.

Путь к файлам начинается с левого меню File Manager. Документ открывается щелчком, действия вызываются меню с тремя точками. Через него файл можно скачать. В Scope те же файлы могут появляться как attachments и placeholders конкретной задачи, поэтому File Manager и матрица поставок не являются двумя независимыми хранилищами.

Экспортированные из Docs и Scope материалы также сохраняются в File Manager. Для документов это PDF и Word; для Scope встречаются PDF, Excel, MS Project и другие специализированные форматы. Автоматический PDF export создаёт новые версии в File Manager по расписанию. Таким образом, утверждённый документ не требуется вручную скачивать на компьютер и снова загружать в проект ради версии.

Состояния и контроль файлов

В CDE-процессах Plannerly использует организацию по состояниям наподобие Work in Progress, Share, Publish и Archive. Смысл состояния — отделить рабочую информацию от той, что разрешена для обмена или публикации. Одного имени файла недостаточно: версия, состояние и права доступа вместе определяют, может ли документ использоваться как актуальная выдача.

Для контроля File Manager полезно сочетать naming convention с метаданными, а не пытаться закодировать всё в имени. Код проекта, дисциплина и тип документа могут быть частью стандартизованного имени; статус согласования, автор, версия и Work Package удобнее хранить как отдельные атрибуты, если проектная схема это предусматривает.

Электронное согласование и подпись

В workflow Plannerly файл можно направить на согласование и электронную подпись. Через File Approval Status выбираются signatories, после чего участник получает документ для review и подписи. В цепочке сохраняются статусы и временные отметки. Электронная подпись помогает зафиксировать согласование внутри проектного процесса, но юридическую достаточность конкретного метода для договора всё равно нужно оценивать по применимому праву и условиям проекта.

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

Когда File Manager лучше использовать вместе с внешним CDE

Некоторые организации уже обязаны хранить проектные файлы в корпоративном CDE. В этом случае Plannerly можно использовать как слой требований, BEP, Scope и Verify, а финальную публикацию сохранять в корпоративной системе. Это не противоречит архитектуре продукта: интеграция с Autodesk ACC/BIM 360 как раз рассчитана на подключение внешнего хранилища к проверке.

Дублирование становится проблемой, если оба CDE объявлены единственным источником истины. До запуска следует зафиксировать, где хранится договорная версия, где рабочая, кто публикует, как синхронизируется version number и какой идентификатор связывает объект в двух системах. Plannerly не может исправить организационную неопределённость одним интеграционным коннектором.

Форматы, импорт, экспорт и интеграции

Plannerly работает сразу с несколькими классами данных, поэтому список форматов следует читать по модулю. Документный формат Docs, требования Scope и BIM-модель Verify выполняют разные функции. Нельзя сделать вывод, что любой поддерживаемый модельный файл можно экспортировать из Docs или что любой офисный документ превращается в проверяемую модель.

Заявление о более чем 80 поддерживаемых типах файлов относится к проверке и работе с проектной информацией в платформе в целом. Для производственного регламента лучше перечислять только те форматы, которые действительно использует конкретная команда, и тестировать их на реальном шаблоне модели. Это особенно важно для проприетарных CAD/BIM-файлов, где качество извлечения свойств может зависеть от структуры исходника.

buildingSMART Data Dictionary и IDS

Scope интегрируется с buildingSMART Data Dictionary. В Project Settings выбираются data dictionaries, по которым выполняется поиск классификаций и information requirements. Вместе с IDS это даёт openBIM-сценарий: требование формулируется как структурированная спецификация, передаётся между системами и затем проверяется против IFC-модели.

IDS полезен там, где текстовое требование «каждая дверь должна иметь…» недостаточно однозначно. В спецификации можно определить применимость, требуемые свойства и допустимые значения. Plannerly способен импортировать IDS в Scope и использовать требования при проверке. Однако корректный IDS по-прежнему нужно спроектировать: машинная читаемость не гарантирует, что бизнес-требование сформулировано правильно.

Autodesk ACC/BIM 360 и Autodesk Forma

Интеграция Plannerly с Autodesk связывает Verify с проектными hubs. В документации Plannerly по-прежнему используется обозначение ACC/BIM 360, а после ребрендинга Autodesk в марте 2026 года Autodesk Construction Cloud вошёл в Autodesk Forma; часть названий продуктов Autodesk изменилась. Поэтому в существующих проектах пользователь может встретить старое и новое имя одной экосистемы одновременно.

Прямое подключение Autodesk ACC/BIM 360 к Verify доступно в планах Team и Enterprise. Для подключения администратор Autodesk включает приложение Plannerly на уровне нужного hub. Затем в Plannerly Manager открывает Verify и использует Connect ACC для выбора доступного пространства. Доступ к файлам не обходит разрешения Autodesk: пользователь должен иметь права в самом hub. Если hub не отображается, сначала проверяют включение приложения Plannerly, права учётной записи Autodesk и то, что интеграция активирована именно в нужном hub.

Связка полезна тем, что модель не требуется вручную копировать между системами после каждой публикации. Verify получает версию из Autodesk-среды, а Plannerly сохраняет логику требований и проверки. Это позволяет оставить корпоративное хранение в Autodesk, а BIM planning и compliance workflow вести в Plannerly.

Microsoft Entra ID и корпоративная авторизация

Для организаций Plannerly поддерживает Microsoft Entra SSO. В Entra создают App Registration с именем Plannerly, типом аккаунтов внутри организации и web redirect URI приложения Plannerly. Затем через Enterprise applications назначают пользователей и группы. После настройки администратор Plannerly может запросить ограничение домена методом Microsoft-only, чтобы исключить вход по локальному паролю или другим социальным провайдерам для корпоративного домена.

SSO влияет не только на удобство входа. При увольнении сотрудника или изменении группы доступ можно централизованно остановить в корпоративном каталоге. Для проекта с чувствительными данными это надёжнее, чем поддерживать набор независимых паролей. При внедрении Entra следует заранее проверить Conditional Access, MFA и назначение групп, иначе пользователь будет видеть Plannerly как доступное приложение, но авторизация остановится политикой Microsoft.

Базовый рабочий процесс от BEP до проверки модели

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

1. Создайте проект и роли. Задайте название, язык и участников. Менеджерам оставьте административные права, редакторам — нужные рабочие области, наблюдателям — Viewer.
2. Соберите управленческий документ в Docs. Откройте Docs, выберите подходящий template или создайте секции вручную. Для BEP заполните сведения о проекте, ролях, обмене информацией, процедурах согласования и правилах моделирования.
3. Вынесите повторяющиеся сведения в SmartFields. Название проекта, адрес, даты и названия команд не следует копировать в десятки секций. Связанные поля упрощают обновление.
4. Создайте структуру Scope. Сформируйте родительскую папку и discipline folders. Добавьте milestones через Plus Milestone. В учебном полном workflow используются примеры Pre Construction и Operation, но реальный проект может содержать concept, detailed design, construction, commissioning и другие точки.
5. Добавьте task rows для deliverables. Каждая строка должна обозначать понятный информационный контейнер: модель, drawing set, room data sheets, отчёт или пакет данных. Не объединяйте в одну строку элементы, у которых разные ответственные и сроки.
6. Заполните ячейки milestone. Добавьте document placeholders, checklists и acceptance criteria. Для будущего файла укажите ожидаемое имя и формат; для уже существующего используйте Add from existing files.
7. Сформируйте information requirements. Определите Pset или group, property title, описание, allowed values, units и verification rule. Проверьте названия против bSDD или принятых проектных словарей.
8. Назначьте Work Packages и команды. Пакет должен отражать реальную ответственность. Отфильтруйте Scope по каждому пакету и убедитесь, что команда видит только свои обязательства, а не случайную смесь дисциплин.
9. Перенесите задачи в Timeline. Задайте длительности, календарные даты и зависимости. Назначьте конкретных исполнителей там, где ответственность не ограничивается названием организации.
10. Согласуйте scope. Для договорной фиксации сформируйте PDF-представление Scope с нужными разделами и проведите предусмотренное проектом согласование или eSignature.
11. Примите файлы. Исполнитель загружает документ в placeholder или публикует модель через связанную среду. File Manager сохраняет версию и контекст.
12. Проиндексируйте модель в Verify. Запустите Processing/Process now, дождитесь индексации свойств и создайте связи между tasks и соответствующими элементами модели.
13. Запустите правила и разберите ошибки. Отделите Missing от Incorrect, проверьте точные имена параметров, Pset и иерархию. После исправления исходной модели опубликуйте новую версию и повторите проверку.
14. Подготовьте отчёт. В Docs добавьте Dashboard charts из Verify, примените Work Package filters и настройте автоматическую PDF-версию, если отчёт должен выпускаться регулярно.
15. Зафиксируйте результат. Перед milestone проверьте статусы документов, версии, signatures, completion требований и наличие утверждённого файла в принятом CDE.

Наиболее важная проверка этой последовательности — трассируемость. Для каждого критичного requirement должно быть понятно, в каком документе оно определено, к какой Scope task относится, кто отвечает, какой milestone применим, где лежит фактический файл и каким правилом подтверждается соответствие. Если один из этих переходов отсутствует, workflow превращается в набор красивых экранов без управленческой цепочки.

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

Поскольку Plannerly — облачный сервис, производительность делится на две части: отзывчивость браузерного интерфейса и серверные операции, такие как обработка модели или экспорт. Для Docs и Scope пользователь в основном зависит от объёма отображаемого содержимого и сетевого соединения. Для Verify основная тяжёлая операция — извлечение и индексирование данных модели.

Опубликованный пример даёт полезный ориентир: Revit-файл около 150 MB обычно обрабатывается 5–20 минут. Разброс объясняется сложностью модели. Два файла одинакового размера могут различаться количеством элементов, количеством свойств на элемент и общей массой извлекаемых данных. Поэтому оценивать очередь проверки только по мегабайтам неправильно.

Во время processing модель всё ещё можно открыть в Viewer без автоматической проверки. Доступны walkthrough, measurement, cross-sections, model tree и property inspection. Это позволяет начать визуальное изучение, пока индекс создаётся. Но статус compliance до завершения processing считать финальным нельзя, потому что rules ещё не получили полный набор данных.

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

В Docs масштабирование связано с количеством секций и SmartFields. Обновление апреля 2026 года добавило поиск и фильтры именно потому, что в больших проектах число SmartFields может достигать десятков и сотен. Для таких шаблонов названия полей должны иметь устойчивую систему. Поле `Milestone 18 Title` информативнее, чем `Field 97`, но ещё лучше корпоративная схема, где по имени ясно, к какому типу данных относится значение.

В Scope крупная сетка управляется через folders, View Preferences, Work Packages и поиск. Вместо того чтобы держать все дисциплины и все виды полей открытыми, пользователь фильтрует рабочий контекст. Это уменьшает визуальную нагрузку и снижает риск редактировать не тот deliverable.

Системные требования

Plannerly не имеет публичного десктопного установщика, поэтому для него нет привычной таблицы минимальных CPU, RAM, GPU и свободного места на диске. Основное приложение работает в браузере. В материалах Plannerly для web scheduler прямо указана работа в Safari, Chrome и других браузерах; для учебной среды лучшая поддержка заявлена для актуального Google Chrome. Для основной производственной работы разумно использовать обновлённый браузер на ноутбуке или настольном компьютере и стабильное интернет-соединение.

Для корпоративной сети системным требованием фактически становится доступ к доменам и провайдерам авторизации. Firewall, proxy, блокировщики и Conditional Access способны остановить login или встроенный контент даже на мощной рабочей станции. Перед развёртыванием полезно проверить приложение из целевой офисной сети, а не только с домашнего подключения администратора.

Если основная нагрузка — Verify больших моделей, локальная мощность компьютера не является единственным фактором, потому что processing выполняется как облачная операция. Однако браузер всё равно должен отрисовывать 3D-сцену. Поэтому старый ноутбук с ограниченной графикой может быть приемлем для Docs, но неудобен для интерактивного просмотра крупной модели.

Безопасность, приватность и управление доступом

Plannerly хранит проектную информацию в облачной среде, поэтому безопасность начинается с управления аккаунтами и ролями. Для каждого участника следует выдавать минимально достаточный доступ. В январе 2026 года платформа расширила role-based access control: разрешения теперь отдельно управляют видимостью команд и участников, доступом к Docs, Scope, Verify и File Manager, возможностью изменять SmartFields, milestones, модели, linking rules, файлы и eSignatures.

При регистрации и использовании сервиса обрабатываются данные учётной записи и технические сведения, связанные с работой веб-приложения. В условиях использования перечисляются, среди прочего, email, данные аккаунта, device identifiers, журналы, транзакционные сведения и пользовательский контент. Для платного аккаунта платёжные данные могут обрабатываться платёжными провайдерами. Организации с требованиями GDPR, локальными политиками или отраслевыми ограничениями должны включать Plannerly в собственную оценку поставщика облачных услуг, а не считать наличие входа по SSO достаточным подтверждением соответствия.

Права на созданный пользователем контент сохраняются за пользователем или организацией, однако сервис получает лицензию, необходимую для хранения, обработки, передачи и отображения материалов в рамках оказания услуги и её поддержки. Если пользователь подключает third-party application, часть контента может передаваться этому провайдеру в рамках выбранной интеграции. Перед подключением внешнего CDE, identity provider или другой системы следует проверить, какие данные действительно должны пересекать границу между сервисами.

Корпоративный контроль желательно строить в несколько слоёв: Entra SSO или другой централизованный метод входа; role-based permissions внутри Plannerly; доступы к конкретным Autodesk hubs при интеграции; статусы и версии файлов; отдельные процессы approval и signature. Такая схема помогает избежать ситуации, когда человек лишён роли Editor в Plannerly, но всё ещё имеет доступ к первичной модели в подключённом CDE.

Резервирование критичных документов также относится к безопасности данных. Version History защищает от части неудачных редактирований, но полностью удалённый документ Docs не восстанавливается стандартной командой. Для утверждённых BEP, соглашений и отчётов имеет смысл сохранять экспортированные версии в File Manager и, если политика организации требует, во внешнем корпоративном хранилище.

Практические сценарии применения

BEP для проектной команды

BIM-менеджер создаёт документ в Docs из BEP template, заменяет общие поля проектными SmartFields и разбивает ответственность по секциям. Архитектор редактирует раздел modelling procedures, инженер — требования к своим deliverables, заказчик — разделы acceptance и exchange. Перед публикацией Manager открывает Version History, сравнивает текущую версию с предыдущей и направляет документ на согласование. Финальная версия экспортируется в PDF и Word, а PDF сохраняется в File Manager.

В этом сценарии главная польза Plannerly не в наличии текстового редактора, а в параллельной работе и связанности повторяемых данных. Если название milestone меняется, системные поля и связанные секции можно обновить без ручного поиска по десяткам страниц. Ограничение — Docs не имеет отдельного встроенного полнотекстового поиска по содержимому, поэтому для разового поиска приходится разворачивать секции и использовать браузер.

Матрица информационных поставок

Information manager создаёт Scope с родительской папкой IPS/MIDP и discipline folders. По колонкам добавляет milestones. В строках описывает модели, drawing sets, schedules, reports и другие deliverables. В каждой требуемой ячейке создаёт placeholder, назначает формат, team и acceptance criteria. После этого Work Packages дают отдельные представления для архитекторов, инженеров и подрядчиков.

Такой Scope заменяет разрозненную связку из Excel-матрицы, отдельного списка требований и календаря. Но качество результата зависит от гранулярности. Если строка называется просто «Documentation» и включает десятки файлов с разными сроками, Plannerly не сможет показать реальный прогресс. Каждая управляемая поставка должна иметь достаточно точное имя и ответственность.

Проверка свойств IFC или Revit-модели

Команда сначала формирует information requirements в Scope или импортирует IDS. Затем подключает модель в Verify и запускает processing. После индексации задача связывается с элементами модели. Rules проверяют наличие и значение свойств. Если параметр не находится, специалист сверяет точное имя, Pset и уровень иерархии; после исправления в авторинговой системе публикует новую версию.

Для такого сценария Plannerly полезен именно как мост между requirement и model data. Простая 3D-коллизия не является его единственной целью. Например, правило может проверять, что требуемое свойство существует и содержит допустимое значение. Если проекту нужен только clash detection без BEP, Scope и information requirements, специализированный координационный продукт может быть прямее.

Регулярный отчёт для руководителя

После настройки Verify BIM-менеджер добавляет в Docs несколько Live Dashboard charts: общий прогресс, отдельный Work Package по инженерным системам и пакет подрядчика. Затем создаёт PDF export, открывает его в File Manager и задаёт Auto Version Settings. Еженедельный файл формируется по расписанию и либо остаётся в File Manager, либо отправляется указанным получателям.

Отчёт не требует ручного переноса процентов в Excel, но это повышает требования к исходным данным. Перед автоматизацией нужно проверить, что статусы задач обновляются, Work Package назначен правильно, а rules не дают систематических false positive. Автоматическая публикация плохой метрики лишь ускоряет распространение ошибки.

Plannerly вместе с Autodesk-средой

Организация оставляет модели и документы в Autodesk Forma/бывшем ACC, где действует корпоративная схема хранения. Plannerly используется для BEP, требований и Verify. Autodesk admin включает Plannerly app на hub, Manager подключает hub в Verify и выбирает модель. Новые опубликованные версии становятся доступны для контрольного процесса без отдельной ручной копии.

Этот вариант удобен для компаний, которые не хотят менять существующий CDE. Но необходимо решить, какая система хранит договорную копию итогового документа. Если один и тот же PDF версии 4 существует в двух местах, регламент должен объяснять, где находится master и кто отвечает за публикацию.

Образовательный и консультационный сценарий

Plannerly предоставляет отдельную training environment и учебные материалы по BIM и ISO 19650. Для консультанта это удобно как демонстрационная среда, но обучающий аккаунт и аккаунт приложения раздельны. Пользователь может иметь одинаковый email, однако должен зарегистрироваться в обеих системах. При диагностике проблем с входом сначала проверяют, в какой именно среде создан профиль.

Ограничения Plannerly

• Зависимость от Интернета. Это облачное приложение; полноценная работа без соединения не является основным режимом поставки.
• Нет локального установщика и автономной версии. Для организаций, где проектные данные должны оставаться только в изолированной сети, SaaS-модель может не соответствовать политике.
• Нет BIM-авторинга. Ошибку геометрии или параметра исправляют в исходной системе, после чего публикуют новую модель.
• Docs пока полагается на поиск браузера по тексту. Перед Ctrl+F/Command+F секции приходится разворачивать.
• Удалённый документ Docs не восстанавливается штатно. Если нет экспортированной копии, обычного восстановления вкладки нет.
• Model processing занимает время. Для 150 MB Revit опубликован диапазон около 5–20 минут; более сложные файлы требуют планового буфера.
• Автоматическая проверка зависит от качества правил. Неверная группа, лишний пробел в имени свойства или неправильная выборка элементов приводит к ошибочному результату.
• Интеграция не заменяет права внешней системы. ACC/BIM 360 hub должен быть активирован администратором, а пользователь обязан иметь доступ к нему.
• Широкие таблицы требуют контроля макета. Для экспорта приходится использовать Landscape, Document View и иногда чистить импортированные стили.
• Стандарт не «встроен вместо компетенции». Шаблон ISO 19650 и автоматизированная проверка не решают вопросы назначения, терминологии и договорной ответственности без квалифицированной настройки.

Плюсы и минусы

Плюсы

• Docs, Scope, Verify и File Manager связаны в одной проектной модели, поэтому requirement можно довести от текста до фактической проверки.
• Scope хранит milestones, deliverables, information requirements, placeholders, acceptance criteria и Work Packages в структурированной форме.
• Verify извлекает свойства модели и проверяет их по заданным правилам, а не ограничивается визуальным просмотром 3D.
• Поддерживаются openBIM-механизмы, включая IFC, IDS и buildingSMART Data Dictionary.
• Docs имеет Version History, сравнение редакций, SmartFields, Section References, согласования и экспорт PDF/DOCX.
• Live Dashboards получают данные из Verify и могут фильтроваться по Work Package.
• Автоматические версии PDF по расписанию сохраняются в File Manager и при необходимости отправляются получателям.
• Ролевые права детализированы по модулям и операциям, что полезно для крупных команд.
• Есть интеграция с Autodesk ACC/BIM 360/Forma и корпоративная авторизация через Microsoft Entra.
• Русский присутствует в перечне языков интерфейса; язык пользователя и язык проекта настраиваются отдельно.

Минусы

• Платформа требует браузера и сетевого доступа; автономный desktop workflow отсутствует.
• Для редактирования геометрии или параметров нужен исходный BIM/CAD-инструмент.
• Полнотекстовый поиск Docs менее удобен, чем отдельный индекс: используется поиск браузера по развёрнутым секциям.
• Ошибочно удалённую вкладку Docs нельзя вернуть стандартной командой восстановления.
• Сложные модели требуют времени на processing перед автоматизированной проверкой.
• Точная конфигурация Verify чувствительна к именам свойств, Pset и иерархии модели.
• При совместной работе с внешним CDE необходимо отдельно договориться, где находится authoritative version.
• Числовая стоимость корпоративного внедрения не сводится к одному публичному тарифу: нужно учитывать роли, места, проекты, SSO и требования к поддержке.

Частые ошибки и способы проверки результата

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

Отзывы пользователей и профильных изданий

Публичная обратная связь о Plannerly неоднородна по независимости, поэтому её полезно разделять на три группы: testimonials, опубликованные самим продуктом; обсуждения специалистов без формального рейтинга; практические обзоры и walkthrough от BIM-профессионалов. Числовые оценки из каталогов без проверяемой актуальной карточки здесь не используются.

Что отмечают пользователи

В профессиональном обсуждении BIM на Reddit прозвучала важная критика: Plannerly не заменяет знание ISO 19650. Участники прямо разделяют программный framework и компетенцию information manager. Это хорошо согласуется с реальным устройством сервиса: шаблон способен предложить структуру, а Verify — проверить формальное правило, но программа не определяет за команду, какое требование договорно оправдано, кто должен быть appointing party и какой acceptance criterion уместен на конкретной стадии.

Такой отзыв особенно полезен новичку, потому что снимает ложное ожидание «купить compliance». Если проект использует ISO 19650, сотрудникам всё равно необходимо понимать процессы, национальные приложения и проектные договорённости. Plannerly сокращает ручные операции вокруг этих процессов, но не превращает автоматически любую настройку в корректную реализацию стандарта.

Testimonials, размещённые на ресурсах Plannerly, преимущественно хвалят централизацию BIM-management workflows, визуальное планирование и вовлечение команды. Эти мнения показывают реальные сценарии использования, но не являются независимым сравнительным тестом: владелец продукта сам отбирает материалы для своей витрины. Поэтому из них можно извлечь повторяющиеся темы, но нельзя выводить универсальную удовлетворённость или процент успешных внедрений.

Практические обзоры BIM-специалистов

Развёрнутый материал BIM-менеджера Clive Jordan о Plannerly положительно оценивает переход от разрозненных документов и таблиц к связанному процессу. Важная оговорка самого автора — текст появился после обращения со стороны Plannerly, хотя оплата за публикацию не заявлялась. Это делает материал полезным как профессиональный walkthrough, но требует учитывать связь автора с вендором при оценке выводов.

Независимые видеообзоры и демонстрации чаще рассматривают Plannerly не как универсальный BIM suite, а как инструмент планирования, отслеживания, approval и verification. Такая рамка точнее рекламного перечня функций: сильная сторона сервиса находится в информационном управлении, а не в создании 3D-контента.

Для покупателя важнее всего повторяемое наблюдение из разных типов отзывов: Plannerly понятнее оценивать на собственном BEP, Scope и одной модели, чем по общей фразе «BIM management». Пробный проект быстро показывает, совпадает ли терминология компании с данными Scope, хватает ли granularity permissions и насколько удобно участникам проходить согласование.

Что нельзя выводить из отзывов

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

Нет оснований называть Plannerly безусловно лучшей BIM-management системой. Платформа заметно отличается от CDE, issue trackers и authoring tools, поэтому рейтинг без единого сценария сравнивал бы несопоставимые задачи. Правильный вопрос — какие части information management команда хочет соединить и какие системы уже закреплены контрактом.

Сравнение с аналогами

Ближайшие альтернативы пересекаются с Plannerly только частично. Autodesk Forma Data Management сильнее ориентирована на документный CDE и управление файлами; BIMcollab — на openBIM requirements, model coordination и BCF/IDS; Revizto — на 2D/3D coordination, issue tracking и работу с пространственно привязанными замечаниями. Plannerly выделяется связкой Docs + Scope + Verify, где BEP и requirements живут в одном процессе с проверкой.

Plannerly и Autodesk Forma Data Management

Autodesk после 24 марта 2026 года включил Autodesk Construction Cloud в Forma и переименовал Autodesk Docs в Forma Data Management. Этот продукт централизует документы, поддерживает naming standards, статусы, версии, approval workflows и ISO 19650-oriented document control. Для организации, уже работающей в Autodesk ecosystem, он естественно становится основным CDE.

Plannerly рациональнее, когда задача начинается не с файла, а с требования: что именно надо предоставить, к какой стадии, кто отвечает и как проверить свойство модели. Поэтому две системы часто не взаимоисключающие. Plannerly может подготовить scope и выполнить Verify, а Autodesk — оставаться authoritative repository. Выбирать одну вместо другой стоит только после ответа на вопрос, где находится основная боль: в договорённости о deliverables или в корпоративном управлении файлами.

Plannerly и BIMcollab

BIMcollab построен вокруг IFC, BCF и IDS и объединяет requirements, model coordination, issue management и information takeoffs. Он особенно силён там, где openBIM и BCF-issues связывают разные авторинговые продукты. В BIMcollab Zoom IDS применяется для property validation, а найденные несоответствия могут становиться BCF issues.

Plannerly ближе к BIM-management planning: Docs для BEP, Scope для ответственности и поставок, Verify для проверки. Если команде нужен централизованный BEP и контрактная матрица требований перед model check, Plannerly предлагает более прямую связку. Если центральный процесс — federated IFC coordination, issue exchange и BCF, BIMcollab может быть естественнее.

Plannerly и Revizto

Revizto концентрируется на 2D/3D issue management. Замечание можно создавать и отслеживать непосредственно в модели или чертеже, связывать с пространственным положением, использовать markups, stamps, workflows и automation. Collaboration Hub объединяет drawings, 3D models, scan data и issue history.

Plannerly следует выбирать не вместо Revizto «вообще», а когда основным объектом управления являются требования и информационные поставки. Revizto прямее для clash/issue coordination на модели; Plannerly — для подготовки BEP, Scope, acceptance criteria и последующей requirement validation. В сложной организации эти продукты тоже могут занимать разные этапы одной цепочки.

Как выбрать Plannerly для конкретной команды

Для пилота достаточно одного небольшого проекта, но он должен быть репрезентативным: реальный BEP, несколько discipline folders, два milestones, один Work Package, один IFC или Revit-файл и несколько правил. Пустая демонстрация без моделей и договорного контекста не покажет главные преимущества и риски.

FAQ по Plannerly

Нужно ли скачивать Plannerly на компьютер?

Нет. Основное приложение работает как web service в браузере. Публичного установщика, который требовался бы для стандартной работы с Plannerly, нет; размер карточки поэтому указывается как online.

Plannerly работает на Windows и macOS?

Продукт не привязан к отдельному Windows- или macOS-бинарнику. Рабочая среда — браузер. Для тяжёлого Scope и 3D Verify удобнее ноутбук или desktop с актуальным браузером и стабильной сетью.

Есть ли русский интерфейс?

Да. Russian включён в опубликованный перечень interface languages. Персональный язык меняется в My Profile, а Project Language задаётся отдельно в Project Settings и влияет на проектные шаблоны и экспортируемые материалы.

Можно ли создать BEP?

Да. BEP создаётся в Docs вручную или из template. Пользователь может менять секции, добавлять SmartFields, comments и approvals, а затем экспортировать документ в PDF или Word.

Можно ли импортировать Word?

Да. В Docs есть Import Word Doc. Эта возможность используется и как обходной путь для восстановления содержимого, когда сохранилась экспортированная копия удалённого документа.

Поддерживает ли Plannerly IFC?

Да. IFC используется в model/verification workflow, а Scope также работает с buildingSMART IDS и data dictionaries. IFC можно хранить в File Manager и проверять в Verify после обработки.

Можно ли проверять Revit без экспорта IFC?

Да. Revit/RVT прямо фигурирует среди поддерживаемых model workflows. При подключении Autodesk hub модель можно брать из ACC/BIM 360/Forma-среды, а опубликованные Revit views определяют, какие представления видны в Plannerly.

Сколько длится обработка модели?

Для Revit-файла около 150 MB приведён типичный диапазон 5–20 минут. Сложность зависит от числа элементов и свойств, поэтому время не определяется одним размером файла. До завершения processing Viewer доступен, но automated rules ещё не готовы к финальной проверке.

Можно ли искать текст в Docs?

Специализированного встроенного full-text search по секциям Docs в текущем workflow нет. Нужно развернуть секции и использовать Ctrl+F или Command+F браузера. В Scope есть собственный поиск по строкам, кодам, типам и information requirements.

Восстанавливается ли удалённый документ?

Удалённая вкладка Docs штатно не восстанавливается. При наличии ранее экспортированного файла можно создать DOCX через File Manager и заново импортировать его в Docs, после чего потребуется проверить структуру и статусы.

Можно ли автоматизировать еженедельный PDF?

Да. После создания export он появляется в File Manager. Через Auto Version Settings задаются frequency, days/time и optional recipients. Новые версии могут просто сохраняться в File Manager или дополнительно рассылаться.

Поддерживаются ли электронные подписи?

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

Что делать, если Verify не видит параметр?

Проверить точное имя свойства включая пробелы, затем group/Pset и уровень model hierarchy. Если свойство находится на родительской сборке, в Task Link Settings можно отключить Link Leaf Elements для поиска выше по дереву.

Можно ли использовать Plannerly как CDE?

Да. File Manager хранит файлы, версии и metadata и связывает их с Docs, Scope и Verify. При этом Plannerly можно использовать и вместе с внешним корпоративным CDE, если в регламенте ясно определено место authoritative copy.

Plannerly заменяет Autodesk Forma?

Нет. Продукты пересекаются в CDE-функциях, но имеют разные центры. Forma Data Management сильна в document control, naming и экосистеме Autodesk; Plannerly сильнее связывает BEP, scope, requirements и verification. Интеграция между ними существует именно потому, что совместный сценарий распространён.

Plannerly заменяет BIMcollab или Revizto?

Не автоматически. BIMcollab глубоко ориентирован на IFC/BCF/IDS coordination, а Revizto — на 2D/3D issues и spatial coordination. Plannerly логичнее оценивать как BIM-management и information-requirements platform. Выбор зависит от того, какая сущность главная в процессе: requirement, file или issue.

Итог

Plannerly имеет смысл там, где BIM-проекту нужен единый управленческий контур от BEP и требований до фактической поставки и model verification. Docs отвечает за живые документы и согласование, Scope — за milestones, deliverables и information requirements, Verify — за связь требований с моделью, File Manager — за файлы и версии. Timeline, Work Packages, permissions и Dashboards соединяют эти уровни в повседневный процесс.

Для небольшой команды перед покупкой достаточно проверить три вещи: удобен ли Docs для реального BEP, удаётся ли без искусственных преобразований перенести существующую матрицу требований в Scope и даёт ли Verify правильные результаты на одной типичной модели. Для крупной организации к этому добавляются Entra SSO, детальные roles, правила authoritative CDE и требования к защите данных.

Plannerly не следует выбирать как «ещё один просмотрщик модели» или как замену BIM-компетенции. Наибольшая отдача возникает, когда команда действительно формализует требования до выдачи, связывает их с ответственностью и сроками, затем использует те же данные при приёмке. Если главная задача ограничена 3D-авторингом, clash coordination или простым файловым хранением, специализированная система может оказаться прямее. Если же проблема состоит в разрыве между тем, что было запланировано, что команда обязалась предоставить и что фактически пришло в модели или документе, архитектура Plannerly соответствует этой задаче напрямую.