Интеграция переводческих процессов с системами PLM и ERP предприятия (SAP, Teamcenter)

В крупном промышленном холдинге инженер меняет спецификацию узла в Teamcenter, изменение уходит в производство, а его русская или английская версия появляется через две недели, когда переводчик получит очередную выгрузку по почте. К этому моменту на площадке уже работают по устаревшему тексту. Знакомая картина для компаний, где инженерные данные живут в PLM, учёт и снабжение в SAP, а перевод остаётся ручным процессом сбоку, никак не связанным ни с той, ни с другой системой.

По мере того как казахстанские промышленные группы переходят на SAP S/4HANA и разворачивают PLM-контуры на базе Teamcenter, разрыв между корпоративными системами и переводом становится ощутимым. Мастер-данные, каталоги материалов, инженерные спецификации и регламенты ТОиР существуют на нескольких языках, но перевод к ним прикручен вручную. Разберём, что и как можно интегрировать, какие модели связки существуют и с чего начать проект, чтобы перевод перестал быть узким местом в цифровом контуре предприятия.

Почему тема стала актуальной для казахстанских предприятий именно сейчас

Ещё несколько лет назад вопрос интеграции перевода с ERP и PLM касался единиц компаний. Сегодня он выходит на повестку целого сегмента промышленности, и причина в двух параллельных процессах.

Первый — распространение SAP в тяжёлой промышленности Казахстана. Систему SAP ERP внедряли ещё в нефтегазовом секторе: в частности, в АО «Разведка Добыча КазМунайГаз» проект SAP ERP создавал единую автоматизированную систему управления и упорядочивал доступ к производственным и финансовым данным. Для горнодобывающих компаний SAP S/4HANA закрывает управление производственными планами, добычей, транспортировкой и переработкой руды. Чем больше данных предприятие ведёт в такой системе, тем острее встаёт вопрос их многоязычности.

Второй процесс — вынужденная миграция на S/4HANA. Платформа была представлена в 2018 году, и переход на неё для большинства компаний неизбежен, поскольку основная поддержка прежней версии ERP завершается около 2027 года. Миграция — естественный момент, чтобы пересмотреть и переводческие процессы: если предприятие всё равно перестраивает контур управления данными, встроить в него перевод дешевле, чем прикручивать его потом отдельно.

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

Добавляет остроты и языковая специфика Казахстана. У многих предприятий данные ведутся минимум в трёх измерениях: русский как рабочий язык, казахский как государственный, английский для международных подрядчиков и поставщиков оборудования. Многоязычные мастер-данные здесь не удобство для отдельных отчётов, а требование операционной среды. Чем больше языков, тем дороже обходится ручная синхронизация и тем сильнее выигрыш от того, что перевод привязан к процессу, а не собирается заново под каждую выгрузку.

Почему перевод оказывается оторван от корпоративных систем

SAP и Teamcenter проектировались как источники истины для своих данных, но не как переводческие платформы. Механизмы многоязычности в них есть, однако они рассчитаны на то, что готовый перевод кто-то подготовит и загрузит. У Siemens в Teamcenter за это отвечает среда бизнес-моделирования BMIDE, где задаются правила локализации, списки значений и правила отображения. У SAP есть отдельный SAP Translation Hub для локализации интерфейсов и текстов. Ни то, ни другое не переводит инженерное и техническое содержание само по себе, это лишь места, куда перевод складывается.

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

Отдельная проблема в том, что перевод в такой схеме не накапливает пользы. Одни и те же наименования материалов, единицы измерения и типовые формулировки переводятся заново при каждой выгрузке, потому что нет общей памяти переводов и единого глоссария, привязанных к процессу. О том, как Translation Memory экономит на повторяющейся документации, мы писали отдельно, и в контексте PLM и ERP этот эффект особенно заметен из-за высокой повторяемости данных.

Что именно переводится в PLM и ERP

Прежде чем строить интеграцию, стоит разложить, какое содержание вообще подлежит переводу. Оно разное по природе и требует разного подхода.

В PLM-контуре, то есть в Teamcenter, это инженерные спецификации и ведомости материалов, атрибуты изделий и структуры сборок, конструкторская и технологическая документация, извещения об изменениях. Здесь важна связь перевода с версионностью: переведён должен быть не абстрактный документ, а конкретная ревизия, и при выпуске новой ревизии перевод обязан обновиться следом.

В ERP-контуре, в SAP, переводу подлежат мастер-данные материалов и оборудования, тексты позиций закупок и договоров, регламенты и планы технического обслуживания в модуле ТОиР, каталоги дефектов и работ. Эти данные короткие, но их много, они сильно повторяются и жёстко завязаны на справочники. Ошибка в переводе наименования материала множится по всем документам, где этот материал встречается.

Есть и пограничный слой — документы, которые формируются из систем, но живут в контурах документооборота: пакеты Document Control, передаваемые через Aconex или SharePoint. Логику работы с ними мы разбирали в материале про управление документооборотом на промышленных проектах, и при интеграции важно не задваивать перевод одного и того же содержания в разных системах.

Стоит развести и два принципиально разных пласта: интерфейс системы и содержание данных. Локализация экранов, меню и стандартных сообщений SAP — задача разовая и решается штатными средствами вроде SAP Translation Hub. Перевод же наполнения, то есть конкретных наименований, спецификаций и регламентов, идёт постоянно и меняется вместе с производством. Смешивать эти два потока не нужно: у них разная периодичность, разные исполнители и разная цена ошибки. Интеграция, о которой идёт речь, касается именно содержания.

Три модели связки перевода с корпоративными системами

Связать перевод с SAP и Teamcenter можно на разной глубине. Выбор зависит от объёма, частоты изменений и зрелости ИТ-контура.

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

Вторая модель — коннектор через систему управления переводами. Современные TMS соединяются с внешними системами через API, коннекторы и вебхуки: изменение содержания автоматически создаёт переводческую задачу, без ручного заведения проекта. Так работают связки TMS с CMS, репозиториями кода и корпоративными платформами, и та же архитектура применима к выгрузкам из SAP и Teamcenter. Здесь появляется очередь заданий, обработка повторных отправок и отслеживание статуса перевода прямо в потоке.

Третья модель — непрерывная локализация. Индустрия переводов уже прошла путь от пакетных проектов к постоянному потоку контента, когда перевод инкрементально подтягивается за каждым изменением. Для предприятия это означает, что новая ревизия спецификации или новая позиция каталога уходит в перевод сразу, а не ждёт ежемесячной выгрузки. Как устроен процесс непрерывного перевода для растущих компаний, мы описывали отдельно, и в интегрированном контуре он раскрывается полнее всего.

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

Показать разницу проще на простом примере. Допустим, обогатительная фабрика ведёт каталог запасных частей и регламенты ТОиР в SAP, а конструкторскую документацию на оборудование в Teamcenter. При ручной схеме новая позиция каталога и обновлённая ревизия спецификации переводятся раз в месяц пакетом, и до этого момента снабжение работает с непереведённым наименованием, а ремонтная служба с устаревшей версией регламента. При связке через TMS та же позиция и та же ревизия уходят в перевод в день изменения, подтягивают уже утверждённый термин из глоссария и совпадающие сегменты из памяти переводов, а редактор проверяет только новое. Объём ручной работы падает, а рассинхронизация между системами исчезает как явление. Это не гипотетический выигрыш, а прямое следствие того, что перевод перестаёт быть отдельным пакетным проектом.

Терминология и память переводов как ядро интеграции

Любая из трёх моделей держится на двух активах: памяти переводов и терминологической базе. Без них интеграция превращается в быстрый конвейер, выдающий несогласованные тексты.

Память переводов особенно эффективна именно на данных SAP и Teamcenter, потому что повторяемость здесь высокая. Наименования материалов, типовые строки спецификаций, стандартные формулировки регламентов ТОиР повторяются тысячами. Один раз переведённая и утверждённая единица дальше подставляется автоматически. Роль CAT-инструментов в снижении стоимости корпоративного перевода на таком материале видна нагляднее, чем на связном тексте.

Терминологическая база решает вторую задачу — единство наименований во всех системах. Если один и тот же узел в PLM назван одним термином, а в закупках в ERP другим, снабжение и производство будут говорить на разных языках в буквальном смысле. Единый глоссарий, привязанный к процессу, снимает это расхождение. О том, как устроено создание и управление терминологическими базами для промышленных клиентов, у нас есть отдельный разбор, и при интеграции с корпоративными системами глоссарий становится не вспомогательным файлом, а частью мастер-данных.

Как выстроить проект интеграции: порядок шагов

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

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

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

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

Выберите модель связки под свой объём. Для умеренного потока достаточно регламентированной выгрузки, для интенсивного и постоянно меняющегося содержания оправдан коннектор через TMS. Наращивать глубину интеграции разумнее поэтапно, проверяя каждый уровень на реальной нагрузке.

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

Риски и подводные камни

Интеграция перевода с корпоративными системами спотыкается на предсказуемых вещах, и знание их заранее экономит месяцы.

Кодировки и спецсимволы. Выгрузки из SAP и Teamcenter нередко содержат служебные символы, теги и переменные, которые нельзя переводить и нельзя терять. Их нужно защищать в CAT-среде, иначе загрузка обратно ломается.

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

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

Ложная экономия на прямой автоматизации. Соблазн подключить машинный перевод напрямую к потоку данных велик, но без постредактирования и контроля он опасен на технике. Наименование материала или параметр в регламенте ТОиР, переведённые машиной с ошибкой и ушедшие прямо в справочник, тиражируются по всем документам, где встречаются. Где машинный перевод с постредактированием (MTPE) оправдан, а где нет, стоит решать осознанно и по типам данных, а не включать его по умолчанию на весь поток.

Размытая ответственность за сроки. Когда перевод встроен в поток, его скорость перестаёт быть внутренним делом бюро и становится частью производственного цикла. Поэтому параметры реакции на изменение, приоритеты и допустимые задержки лучше зафиксировать в соглашении об уровне услуг заранее. Без этого «непрерывная» локализация на бумаге оборачивается прежними задержками на практике, только теперь их сложнее отследить.

Опыт iText в корпоративной интеграции перевода

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

Масштаб, на котором интеграция окупается, у команды iText отработан в сотрудничестве с Eurasian Resources Group: через бюро прошло более 35 миллионов страниц технических материалов по объектам горно-металлургического комплекса. Такой объём невозможно вести вручную без памяти переводов и единой терминологии, и именно эта дисциплина делает связку с корпоративными системами работоспособной.

Если у вас на предприятии внедрены SAP или Teamcenter, а перевод по-прежнему идёт ручными выгрузками, начните с малого: инвентаризация переводимого содержания и сборка глоссария по выборке реальных данных. Специалисты iText готовы провести этот первый этап и предложить модель связки под ваш объём и частоту изменений. Опишите нам, какие системы у вас используются, какие данные и на какие языки нужно переводить, и мы предложим порядок работы. Спектр корпоративных направлений бюро собран на странице услуг iText.