Выбирая систему управления бизнесом для своей компании, руководители бюро переводов чаще всего начинают со сравнения доступных функций на каком-нибудь сервисе вроде Capterra. Еще один популярный метод выбора — обратиться к разработчикам с просьбой заполнить специальную таблицу, проставив «да» или «нет» напротив названий всевозможных функций.
Оба эти подхода базируются на фундаментальных заблуждениях, о которых мы поговорим ниже.
Как называется функция?
Как мы уже многократно писали в статьях на нашем блоге, не бывает двух одинаковых бюро переводов: все они уникальны, как отпечатки пальцев. Одно из проявлений этой уникальности — корпоративная терминология: в разных бюро по-разному понимают термины «проект», «работа», «задание», «сумма к оплате» и т. д. А самое главное — по-разному понимают взаимодействие этих сущностей между собой.
Например, в одних компаниях «проект» — это единоразовый заказ от клиента, в других — нечто долгоиграющее, длящееся недели или месяцы, и каждый отдельный заказ считается частью проекта, «подпроектом». В одних бюро «принимают работы» и «дают задания», в других — «получают запросы» и «назначают работы», в третьих — «принимают заказы» и «передают проекты». То, что в одних бюро называется «работой», в других — «проект» или «наряд». Одни платят «гонорары», другие — «зарплаты», третьи — «оплаты», четвертые — «выплаты», пятые — «платежи». Одно бюро переводов создает отдельный счет-фактуру на каждый заказ, другое собирает все заказы клиента за месяц в ежемесячный счет, третьи ждут, когда накопится определенная сумма.
Дополнительные сложности порождает разница в языках. Если ваш родной язык — например, испанский, а интерфейс системы на английском, терминологическая неразбериха усиливается.
По-разному понимаются даже функции сотрудников. Например, в одном бюро переводов менеджер проектов просто распределяет файлы для перевода, в другом — сам выбирает команду и даже ведет переговоры о ценах с клиентами. Есть бюро, в которых от менеджеров проектов скрывается информация об их доходности, а финансовыми вопросами занимается отдельный работник.
Таким образом, в каждом бюро вырабатывается свой «корпоративный диалект» — и в вашем тоже. И если вы обратитесь с вопросами к разработчику системы управления переводческим бизнесом, то с большой вероятностью он извлечет из них не тот смысл, который вы в них вкладывали, и ответит «да» в случаях, когда в вашем понимании нужно было бы написать «нет», или наоборот.
Допустим, вы спрашиваете, предусмотрена ли в системе «функция оплаты работ». Если понимать ваш вопрос буквально, получается, что отвечать нужно «нет», поскольку в системе такая функция не предусмотрена. Но догадливый разработчик поймет: «оплаченной работой» вы называете то, что в логике созданной им системы называется «оплаченный инвойс по проекту». То есть на самом деле функция предусмотрена, но она имеет другое название или выполняемое ею действие реализуется иначе.
Скорее всего, на ваш вопрос ответят «да, есть, и мы вам покажем, как она работает». Но при этом у вас создастся впечатление, что разработчик просто уходит от прямого ответа, хотя это совсем не так.
Как работает функция?
Даже если удалось избежать путаницы с терминами, список доступных функций системы управления переводами мало чем поможет для принятия оптимального решения.
Причина в том, что само наличие функции ничего не говорит о том, как она работает. Например, сколько щелчков мышки нужно сделать, чтобы создать проект? Насколько удобен и интуитивно понятен интерфейс? Сложно ли научиться пользоваться системой и во что обойдется ее внедрение? А вдруг для ознакомления с ней нужно всех менеджеров отправлять на недешевые трехмесячные курсы? Насколько оперативно реагирует на ваши вопросы служба поддержки, если вы чего-то все-таки не поняли? Вы не сможете получить ответы на эти вопросы ни сравнением функций, ни в переговорах с разработчиками.
Как же выбрать систему управления?
Если вы всерьез задумались о внедрении системы управления переводами в своем бюро, не опирайтесь на сравнительные списки. Уверяем вас: под каждым пунктом такого списка, состоящим из одной строки, можно добавить три абзаца нюансов и уточнений.
Список желаемых функций — лишь ориентир; каждую из них нужно протестировать. Важно определить, нравится ли вам интерфейс системы, легко ли в ней работать, понятна ли ее внутренняя логика. Одна и та же операция в двух разных системах (например, «создание проекта») наверняка будет выполняться по-разному, а в сравнительном списке этот факт никак не отразится.
Обязательно протестируйте систему управления переводческими проектами, прежде чем ее покупать и внедрять. Как правило, разработчики предоставляют обучающие материалы, позволяющие быстро приступить к работе. Уделите немного времени ознакомлению с ними.
Общайтесь с разработчиками, описывая свои практические задачи, задавайте им конкретные вопросы. Так вы проверите «отзывчивость» технической поддержки пользователей. Если вам отвечают быстро и понятно, вы не останетесь наедине с непонятными вам кнопками. Скорее всего, требуемая вам функция реализована в системе, нужно лишь разобраться, как именно она работает.
Разработчикам нужно знать, как устроены производственные процессы в вашем бюро переводов, что именно вам требуется. Обычно они страдают от нехватки отзывов, помогающих определить, в каком направлении развивать свой продукт. Вполне возможно, что, основываясь на ваших рекомендациях, они внедрят нужные вам функции в следующих релизах своих программ.
