Строить не покупать. О разработке портала GTP в Janus Worldwide:

Семь из десяти крупнейших переводческих компаний в России разработали системы автоматизации бизнеса самостоятельно, вместо того, чтобы покупать готовые решения. В Janus Worldwide в разработку вложили $100 тысяч и 5 лет работы команды из 6 человек. Получился портал для взаимодействия с клиентами GTP (Global Technology Platform). К концу 2020 года на него перешли 50 из нескольких сотен клиентов компании. Об этом пути рассказывает Наталья Рудинская, product owner.

C:\Users\n_rudinskaya\Desktop\IMG_0605.jpg

 

– Наташа, как сейчас используется платформа? Кто ей пользуется?

— Портрет клиента обычно такой:

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

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

– Как появилась GTP?

— Как идея она родилась еще в 2017-ом. Я работала сначала менеджером проектов, когда часть переводов выполнялись просто в Word, затем появился Trados 2007, разные таблицы велись в эксельках, несмотря на наличие ERP – там изменения внедрялись долго.

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

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

Тут пришло понимание, что нужно дать возможность клиенту закинуть куда-то файл, получить расчет затрат и сроков, и если все устраивает, подтвердить запуск:

Было важно сделать так, чтобы клиент мог визуально найти нужный проект и следить за его прогрессом, чтобы не переспрашивать: «Готов ли перевод, успеем ли к дедлайну, потому что это крайне важно?». Это привело к желанию собрать весь нужный функционал на одной платформе, ведь по сути у нас для этого уже были заготовки в ERP еще лет 7 назад.

Сейчас не вспомню точно, кто именно первым озвучил идею, но конечно решающим было слово Константина Иоселиани, Президента нашей компании, и Игоря Могилевского, Вице-президента Янус по технологиям, после чего мы уже не видели будущего без нового технологического решения.

Версия GTP 2018 года

Версия GTP 2020 года

Первая версия вышла совсем голой и малофункциональной, но мы увидели первое воплощение идеи во что-то, что можно увидеть и «пощупать». ☺

– Почему не купили что-нибудь готовое, ведь это дешевле и проще?

— Вопроса о покупке готового решения не возникало, потому как у нас большой практический опыт и созданная под наши процессы внутренняя ERP. Тогда зачем платить за то, что уже есть? И не хотелось дополнительно тратить силы и время, чтобы объяснять сторонним разработчикам тонкости работы на проектах в локализации.

– В России сотни предприятий с сотнями несовременных служб переводов, где достаточно памяти переводов плана Trados, а управление проектами они ведут в блокноте и о ТМS не слышали. Ты пробовала с Across поменять это, но совсем не зашло? Почему?

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

Версия GTP 2020 года

– Как ты решила спрыгнуть с производства на технологии. Что за этим стоит? Что тебя зажгло?

— Работая как руководитель отдела, со временем я стала много общаться с клиентами о расширении сотрудничества, поиске путей оптимизации их затрат и формата работы с нами, как с переводческой компанией. Запускала сложные проекты, а менеджерам своего отдела передавала работу на устоявшихся линейках – так я стала отходить от рутинного производства. Работать непосредственно на проектах и одновременно развивать технологии становилось все сложнее, поэтому я приняла болезненное решение оставить на тот момент уже три своих отдела и погрузиться в GTP.

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

– В двух словах: порталов много, проникновение их невысокое, куда чаще используются коннекторы и FTP. Но у команды Янус есть план, идея, вас волнует вопрос автоматизации работы с клиентом. Почему именно портал?

— Коннекторы и FTP покрывают только часть менеджерского функционала, остальное берут на себя CAT и TMS. В любых комбинациях получается, что приходится использовать несколько инструментов и дублировать действия, а чтобы не забыть что-то, опять возвращаться к таблицам в эксель…

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

Хотя без коннектора не обойтись в некоторых случаях. 🙂 Если у клиента особые требования безопасности и нет возможности использовать серверное решение или необходим доступ к большей отчетности, ведению базы исполнителей с их рейтингом и отслеживанием качества их работы, мы предлагаем установку системы на сервер клиента и коннектор с Janus ERP. Но это уже другая история.

 

Примечание Константина Дранча: Как оценить разработку со стороны?

В мире примерно треть переводческих компаний разрабатывает собственные системы управления. Процесс этот бесконечный, как только версия X готова, нужно начинать версию X+1. Наиболее технически продвинутые команды в средних переводческих фирмах, например, TranslateMedia в Великобритании и BureauWorks, включают по 6-10 разработчиков, которые загружен на полный день и полный год.

Разрабатывать дорого. Не раз бывало, что более крупные ПК в Германии и Скандинавии вбухивали $1-2 миллиона в разработку, а затем выбрасывали все на свалку истории, покупали готовое и строили вокруг готового.

В сравнении с этими проектами у команды Janus получилось малыми инвестициями добиться стабильной неплохой системы. До уровня мировых лидеров не хватает документированного REST API, большого парка коннекторов и интеграций, внешних компонентов на машинном обучении. Но уже достигнутого достаточно чтобы обогнать 80% компаний на рынке. 

Поделиться в соцсетях

Комментарии

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Будьте в курсе новостей и технологий переводческого бизнеса
Подпишитесь на рассылку Translationrating