Вибираючи систему керування бізнесом для своєї компанії, керівники бюро перекладів найчастіше починають із порівняння доступних функцій на якому-небудь сервісі на зразок Capterra. Ще один популярний метод вибору — звернутися до розробників із проханням заповнити спеціальну таблицю, проставивши «так» або «ні» навпроти назв різноманітних функцій.
Обидва ці підходи базуються на фундаментальних помилках, про які ми поговоримо нижче.
Як називається функція?
Як ми вже багаторазово писали в статтях у нашому блозі, не існує двох однакових бюро перекладів: усі вони унікальні, як відбитки пальців. Один із проявів такої унікальності — корпоративна термінологія: у різних бюро по-різному розуміють терміни «проект», «робота», «завдання», «сума до сплати» тощо. А найголовніше — по-різному розуміють взаємодію цих понять між собою.
Наприклад, в одних компаніях «проект» — це одноразове замовлення від клієнта, в інших — щось довготермінове, яке триває протягом тижнів або місяців, і кожне окреме замовлення вважається частиною проекту, «підпроектом». В одних бюро «приймають роботи» й «дають завдання», в інших — «отримують запити» й «призначають роботи», у третіх — «приймають замовлення» та «передають проекти». Те, що в одних бюро називається «роботою», в інших — «проект» або «наряд». Одні платять «гонорари», інші — «зарплати», треті — «оплати», четверті — «виплати», п’яті — «платежі». Одне бюро перекладів створює окремий рахунок-фактуру на кожне замовлення, інше збирає всі замовлення клієнта за місяць у щомісячний рахунок, треті чекають, коли накопичиться певна сума.
Різниця в мовах породжує додаткові ускладнення. Якщо ваша рідна мова — наприклад, іспанська, а інтерфейс системи англійською, термінологічна плутанина посилюється.
По-різному розуміють навіть функції співробітників. Наприклад, в одному бюро перекладів менеджер проектів просто розподіляє файли для перекладу, в іншому — сам вибирає команду та навіть веде переговори про ціни з клієнтами. Є бюро, у яких від менеджерів проектів приховується інформація про їхню прибутковість, а фінансовими питаннями займається окремий працівник.
Таким чином, у кожному бюро виникає свій «корпоративний діалект» — і у вашому теж. І якщо ви звернетеся з питаннями до розробника системи керування перекладацьким бізнесом, то з високою ймовірністю він зрозуміє їх не так, як ви мали на увазі, і відповість «так» у випадках, коли у вашому розумінні потрібно було б написати «ні», або навпаки.
Уявімо, що ви запитуєте, чи передбачена в системі «функція оплати робіт». Якщо розуміти ваше запитання буквально, виходить, що відповідати потрібно «ні», оскільки в системі така функція не передбачена. Але кмітливий розробник зрозуміє: «оплаченою роботою» ви називаєте те, що за логікою створеної ним системи називається «оплачений інвойс за проектом». Тобто насправді функція передбачена, але вона має іншу назву, або дія, яка виконується нею, реалізується інакше.
Імовірно, на ваше запитання дадуть відповідь «так, є, і ми вам покажемо, як вона працює». Але водночас у вас складеться враження, що розробник просто уникає прямої відповіді, хоча це зовсім не так.
Як працює функція?
Навіть якщо вдалось уникнути плутанини з термінами, список доступних функцій системи керування перекладами навряд допоможе зробити оптимальний вибір.
Причина в тому, що власне наявність функції нічого не говорить про те, як вона працює. Наприклад, скільки разів потрібно натиснути мишкою, щоб створити проект? Наскільки зручний та інтуїтивно зрозумілий інтерфейс? Чи складно навчитися користуватися системою? Скільки коштуватиме її впровадження? А раптом для ознайомлення з нею потрібно всіх менеджерів відправляти на недешеві тримісячні курси? Наскільки оперативно реагує на ваші запитання служба підтримки, якщо ви чогось усе-таки не зрозуміли? Ви не зможете отримати відповіді на ці запитання ні порівнянням функцій, ні під час переговорів із розробниками.
Як тоді вибрати систему керування?
Якщо ви серйозно задумалися про впровадження системи керування перекладами у своєму бюро, не покладайтеся на порівняльні списки. Повірте: під кожним пунктом такого списку, який містить один рядок, можна додати три абзаци нюансів і уточнень.
Список бажаних функцій — лише орієнтир; кожну з них потрібно протестувати. Важливо визначити, чи подобається вам інтерфейс системи, чи легко в ній працювати, чи зрозуміла її внутрішня логіка. Та сама операція у двох різних системах (наприклад, «створення проекту») напевне виконуватиметься по-різному, а в порівняльному списку цей факт ніяк не відобразиться.
Обов’язково протестуйте систему керування перекладацькими проектами, перш ніж її купувати й впроваджувати. Зазвичай розробники надають навчальні матеріали, які дають змогу швидко розпочати роботу. Приділіть трохи часу ознайомленню з ними.
Спілкуйтеся з розробниками, описуючи свої практичні завдання, ставте їм конкретні запитання. Так ви перевірите оперативність технічної підтримки користувачів. Якщо вам відповідають швидко та зрозуміло, ви не залишитеся наодинці з незрозумілими вам кнопками. Найімовірніше, потрібну вам функцію реалізовано в системі, необхідно лише розібратися, як саме вона працює.
Розробники мають знати, як влаштовані виробничі процеси у вашому бюро перекладів, що саме вам потрібно. Зазвичай їм не вистачає відгуків, що допомагають визначити, у якому напрямку розвивати свій продукт. Цілком можливо, що, ґрунтуючись на ваших рекомендаціях, вони впровадять потрібні вам функції в майбутніх релізах своїх програм.
