Перевод и управление документооборотом на промышленных проектах: Aconex и SharePoint

На мегапроекте расширения Кашагана только один транзиттал типа «Issued for Construction» может содержать 300–500 чертежей и спецификаций. Каждый из них попадает к сотням получателей: EPC-подрядчику, EPCM-консультанту, надзорному органу, страховщику, банку-финансисту. Каждый документ идёт с уникальным номером, ревизией, статусом, штампом заказчика и часто с параллельной русской версией, которую нужно выпустить синхронно с английской. Пропустить одну ревизию — значит запустить бригаду на стройплощадку по устаревшему чертежу. Пропустить одну русскую версию — значит блокировать согласование в надзорном органе Казахстана.

Именно поэтому крупные промышленные проекты в стране, от FGP-WPMP на Тенгизе до газоперерабатывающего завода Кашагана мощностью 2,5 млрд м³ (Energies Media), стоят на Common Data Environment (CDE) — обычно Oracle Aconex или Microsoft SharePoint. Обе платформы обеспечивают контролируемый обмен документами, транзитталы, ревизионный контроль и полный аудит-трейл (Oracle Aconex Overview). Перевод в такой архитектуре — не отдельный процесс где-то сбоку, а такой же поток документов, как проектирование или строительство, со своими метаданными, ревизиями и SLA.

В этой статье разберём, как встроить перевод в Document Control на EPC-проекте в Казахстане, какие метаданные обязательны для двуязычных пакетов, как настроить роли переводчика и редактора в Aconex и SharePoint и как избежать типовых ошибок при работе с ревизиями. Материал написан для руководителей document control, менеджеров проектов, специалистов по закупкам переводческих услуг и корпоративных менеджеров по знаниям.

Общий контекст по организации корпоративного перевода в промышленном холдинге разобран в нашем руководстве по корпоративному переводу для промышленного холдинга.

Что делает Document Control и где в нём место перевода

Document Control — это дисциплина проектного управления, отвечающая за то, чтобы все участники в любой момент времени работали с правильной ревизией правильного документа. У неё три ключевые задачи. Первая — единый источник истины: одна база документов, доступная всем сторонам с правильными правами. Вторая — контроль ревизий: каждое обновление получает новый номер (Rev A, Rev B, Rev 0, Rev 1), а старые версии остаются в архиве, но не могут быть случайно использованы. Третья — прозрачный аудит: кто, когда и что сделал с документом, кому направил, когда согласовал.

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

Правильная модель — перевод как отдельный шаг в workflow транзиттала. Английская ревизия выпускается в CDE, переводческое бюро получает автоматическое уведомление с ссылкой на пакет, готовит русскую версию с сохранением всех метаданных, публикует её в тот же CDE с привязкой к оригиналу и к номеру ревизии. Заказчик и все стороны видят двуязычный пакет как единую сущность.

Oracle Aconex: как перевод встраивается в транзитталы

Oracle Aconex — платформа-стандарт для мегапроектов, где параллельно работают десятки организаций. В казахстанской практике на ней стоят проекты TCO, NCOC, KPO, крупные EPC-подрядчики Petrofac, PowerChina, Sinoma. Каждая организация видит только те документы и коммуникации, которые ей адресованы, но при этом весь проект живёт в едином защищённом пространстве с общим аудит-трейлом (Oracle Aconex Solution Overview).

Для перевода в Aconex есть несколько устоявшихся сценариев. Первый — перевод как отдельный документ с привязкой к оригиналу. Английская версия выпускается с уникальным Document Number вида «TCO-FGP-CIV-DWG-00123», ревизия «Rev B». Русская версия получает тот же Document Number с суффиксом «-RU» или отдельное поле «Language» = «RU», ревизия обычно синхронизируется. При обновлении английской версии до «Rev C» русская автоматически становится устаревшей, пока не будет выпущена «Rev C-RU».

Второй сценарий — перевод как ревизия в поле «Language». Некоторые EPC-подрядчики используют кастомную настройку Aconex, где у каждого документа есть отдельная сущность на английском и на русском, и они связаны через мета-поле «Bilingual Set». Такая модель удобна для документов, обязательных к выпуску сразу на двух языках, например, HSE Plans, Operations Manuals, Procedures.

Третий сценарий — перевод как автоматический workflow. Переводческому бюро создаётся отдельная роль в Aconex, обычно «Translation Reviewer» или «Language Coordinator». Роль настроена так, что при выпуске английского документа с определённым тегом («Requires Russian Translation») автоматически создаётся задача с SLA. Бюро получает уведомление, забирает файлы через CDE, публикует переведённые версии как ответ на транзиттал.

Ключевая рекомендация для настройки: обязательно задать шаблон транзиттала, где поле «Language» и поле «Translation Status» — обязательные при заведении документа в базу. Без этого рано или поздно появятся документы, у которых непонятно, есть ли русская версия и в какой она ревизии.

Мы в бюро технических переводов iText работаем с Aconex по всем трём моделям и берём на себя настройку ролей и workflow совместно с document controller заказчика. Практический опыт: у крупного EPC-подрядчика первичная настройка Translation Workflow в Aconex занимает 1–2 недели, но после запуска сокращает время выпуска русской ревизии в среднем на 40–60% против почтового обмена.

SharePoint: гибкость и типовые ошибки

Microsoft SharePoint — вторая по распространённости платформа Document Control в Казахстане, особенно у корпоративных холдингов уровня ERG, КМГ и «Казатомпром». Для холдингов SharePoint часто удобнее Aconex, потому что уже интегрирован с Microsoft 365, Teams, Azure AD. Но для перевода в SharePoint есть несколько нюансов, которые нужно учитывать при настройке.

Первый нюанс — метаданные. SharePoint позволяет создавать произвольные колонки, но многие проекты стартуют с базовым набором «Title, Author, Modified» и годами не расширяют его. Для перевода критичны поля: Language (RU, EN, KZ), Original Document ID, Translation Status (Pending / In Progress / Completed / Verified), Revision, Bilingual Set ID. Без них двуязычный пакет невозможно собирать автоматически.

Второй нюанс — библиотеки и версионность. По умолчанию версионность в SharePoint включена, но многие команды выключают её из соображений экономии места. На EPC-проекте это категорически противопоказано. Каждая ревизия должна храниться как minor version, каждый утверждённый выпуск — как major version. Только так возможен ретроспективный анализ, что именно и когда выпустили.

Третий нюанс — права доступа. SharePoint по природе гибче Aconex в правах, но эта гибкость опасна: одна неверно назначенная роль может дать переводчику доступ к чувствительным разделам HR или к финансовой документации. Для переводческих подрядчиков создают отдельный SharePoint-сайт или изолированную библиотеку с чётко ограниченными правами и с сохранением аудит-трейла.

Четвёртый нюанс — интеграция с CAT-инструментами. SharePoint из коробки не связан с системами компьютерного перевода. Практическая связка выстраивается через Power Automate: при появлении документа с тегом «Translate to Russian» запускается workflow, который отправляет файл в CAT-инструмент бюро, забирает перевод и возвращает в правильную библиотеку с обновлёнными метаданными. Настройка такого сценария — работа для внешнего интегратора, но окупается на объёмах от 100 000 слов в месяц.

Мы разбирали смежные вопросы SLA и качества в отдельном материале про SLA для переводческих услуг — рекомендуем перечитать перед настройкой SharePoint-workflow.

Метаданные двуязычного документа: минимальный набор

Независимо от платформы, перевод в Document Control работает только тогда, когда двуязычный документ несёт правильные метаданные. Минимальный набор, который мы рекомендуем клиентам в качестве старта:

Document Number — уникальный номер по системе нумерации проекта.

Language — язык версии (EN, RU, KZ, CN).

Revision — номер ревизии, синхронизированный с оригиналом.

Original Document ID — ссылка на оригинал, если это переведённая версия.

Translation Status — статус перевода (Pending, In Progress, Under Review, Approved).

Translator — идентификатор переводческой компании или конкретного переводчика.

Verification Date — дата проверки редактором.

Bilingual Set ID — общий идентификатор для группы связанных языковых версий.

Discipline — дисциплина (Civil, Mechanical, Electrical, Process, HSE, Contracts).

Document Type — тип (Drawing, Specification, Procedure, Report, Manual, Contract).

Этот набор закрывает 90% практических потребностей и совместим и с Aconex, и с SharePoint. Дальше метаданные расширяются под специфику проекта: например, у ТШО есть поле «CPDEP Stage» (Chevron Project Development and Execution Process), у NCOC — «Contract Package».

Ревизии и русская версия: как не отставать

Главная операционная проблема двуязычного Document Control — не отставание перевода на одну ревизию, а накопительное отставание на три-пять ревизий, когда пересобрать актуальную русскую версию уже дороже, чем перевести с нуля. Профилактика этой проблемы держится на нескольких принципах.

Первое: переводить только утверждённые ревизии. Если документ идёт в статусе «Issued for Review», это не финальная версия, замечания ещё будут. Перевод такой ревизии почти гарантированно уйдёт в мусорную корзину. Экономически правильный триггер для перевода — статус «Issued for Construction», «Issued for Approval» или «Approved for Design».

Второе: параллельная очередь под MRR (Minor Revision Review). Если английская ревизия обновляется точечно, часто нет смысла переводить весь документ заново. Настраивается процедура delta-перевода: переводчик получает только изменённые разделы (обычно с треками правок), обновляет русскую версию и повышает её ревизию. Экономия на длинных документах — до 60–80% от полной перевод-стоимости.

Третье: контроль отставания как KPI. Document controller или менеджер по знаниям еженедельно выгружает отчёт «Documents Without Current Russian Revision» из Aconex или SharePoint. Если в этот список попадает документ с высоким приоритетом, срабатывает эскалация. Такой процесс превращает перевод из «неизвестной черной дыры» в управляемый поток.

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

Роли и права: кто что делает в двуязычном workflow

В зрелом двуязычном Document Control обычно определены пять ролей.

Author — автор оригинала (проектировщик, инженер, юрист). Он ставит документу тег «Translate to Russian» при выпуске.

Document Controller — контролирует нумерацию, ревизии, метаданные. При выпуске английской версии проверяет, что тег на перевод стоит там, где нужно.

Translation Coordinator (иногда сам document controller, иногда отдельная роль) — принимает решение о том, куда направить документ: во внешнее бюро, внутренней команде, или на MTPE. Мы разбирали разницу этих сценариев в материале про MTPE для промышленной технической документации.

Translator — переводчик бюро или штатной команды. Работает в CAT-инструменте с глоссарием и Translation Memory клиента. У ERG подобная терминологическая экосистема выстраивалась годами; о нашей роли в ней читайте в кейсе про 35 миллионов страниц.

Reviewer / Verifier — редактор бюро и представитель заказчика, подтверждающий готовность русской версии к выпуску. После верификации Translation Status меняется на «Verified», и документ становится частью двуязычного пакета.

Каждая роль фиксируется в CDE с правами и с ответственностью. Перекрывающиеся или неопределённые роли — источник большинства ошибок, включая выпуск неверной ревизии на стройплощадку.

Типовой пилот: как за 30 дней запустить перевод в CDE

Практика пилотов на промышленных проектах Казахстана сводится к четырёхнедельной схеме, которую мы отработали на нескольких клиентах.

Первая неделя — техническое интервью. Document controller заказчика и координатор бюро проходят по всей проектной иерархии: какие типы документов, какие статусы, какие метаданные, где живут глоссарии и Translation Memory, какие роли и права уже настроены в CDE. По итогам собирается один-двухстраничный документ «Translation Integration Playbook» с конкретной схемой ролей и workflow.

Вторая неделя — настройка. В Aconex или SharePoint создаётся роль переводческого бюро, выделяется библиотека или папка для двуязычных пакетов, настраиваются обязательные поля Language, Translation Status, Original Document ID. Если используется MTPE, подключается CAT-инструмент бюро к CDE через API или Power Automate. На этом же этапе мигрируется существующий глоссарий заказчика — часто это Excel-файлы разной давности, которые нужно объединить и очистить.

Третья неделя — пилотная партия. Обычно 20–50 документов из одной дисциплины, например, HSE Procedures или Mechanical Specifications. Бюро проходит полный цикл: получение через CDE, перевод в CAT-инструменте с глоссарием, редактура, публикация обратно в CDE с полным набором метаданных. Заказчик тестирует, что двуязычные пакеты правильно собираются в отчётах и правильно отображаются у смежных ролей.

Четвёртая неделя — калибровка SLA. По результатам пилота фиксируется реальное время цикла cut-off → готовность русской версии, реальные объёмы delta-переводов при обновлении ревизий, реальная нагрузка на глоссарий. По этой калибровке подписывается рамочный договор с прогнозируемой стоимостью и SLA на регулярный поток.

Такой пилот стоит бюджет одного-двух дней координатора и одного эксперта-переводчика. Экономия от правильно настроенного Document Control — недели пересборки документации в конце фазы проекта.

NDA, конфиденциальность и безопасность в CDE

Работа переводческого бюро внутри Aconex или SharePoint означает доступ к чувствительной корпоративной информации: контракты, финансовые отчёты, HSE-статистика, техническая документация с признаками коммерческой тайны. Стандартное решение — трёхуровневая защита. Первый уровень — NDA между заказчиком и переводческим бюро. Второй — назначенная роль в CDE с минимально необходимыми правами. Третий — регулярный аудит доступа с деактивацией пользователей, которые больше не работают на проекте.

Подробно эту тему разбираем в отдельной статье про конфиденциальность и NDA при переводе.

Готовы обсудить двуязычный Document Control для вашего проекта

Бюро технических переводов iText встраивается в систему Document Control заказчика и работает в её же CDE — Aconex, SharePoint, кастомные корпоративные порталы. Мы помогаем настроить роли, workflow, метаданные двуязычных пакетов и синхронизацию ревизий, поддерживаем регулярный поток переводов для EPC-подрядчиков, промышленных холдингов и крупных заказчиков в нефтегазовой отрасли, металлургии и электроэнергетике Казахстана.

Если ваш проект уже работает в Aconex или SharePoint, но перевод отстаёт от английских ревизий, напишите нам через страницу контактов. По результатам первого технического интервью с вашим document controller мы предложим схему интеграции, чек-лист метаданных и рамочный договор с SLA.

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