It wasn’t all that long ago that computer-aided translation tools and translation memory (TM) were a new concept. By the late 1990s, language service providers (LSPs) began requiring translators to use this technology. Some users were reluctant to adopt, but savvy early adopters reaped the benefits of faster, more consistent translation. The translation cost savings due to reuse was so large and margins so greatly increased that it quickly became common practice for LSPs and payment to translators was no longer based on total word count, but on TM leverage statistics, even including repeat text within a new project. It did not take long for LSPs to start passing on some of these cost savings to clients in order to win accounts, and as clients gained visibility into the practice, a new standard was established.
TM reuse was now standard practice and given transparency in the form of leverage statistics and per-word fees based on percentage match value in job quotes. TM updates were manual and TM was maintained on an LSP desktop or network where clients could not see them or monitor usage outside of what the LSP reported. Inconsistent leverage of TM was apparent to any client or LSP processing a single source for multiple languages on a regular basis. The reason? Sometimes translators or project managers forgot to update the TM. Sometimes the TM went missing. Sometimes a TM that should have been leveraged was mistakenly omitted during analysis. So how does one ensure that the TM is consistently updated and reused? The answer is workflow automation. Enter the translation management system (TMS).
Commercially available TMSs were firmly on the scene by 2005. They offered the ability to automate TM updates, file distribution for the translation workflow stages and QA checks. TMS was a big ticket item, with a base cost of hundreds of thousands of dollars per year. Pricing varied greatly, depending on throughput, customization, length of commitment and procurement negotiation. Small companies interested in the technology had trouble even getting the attention of the salespeople when their throughput and/or budget was not large enough to entertain the idea of the substantial investment. This went on for years and smaller companies continued to depend solely on desktop translation tools, despite the existence of workflow automation in TMS.
Enter the disrupters
Smaller technology vendors popped up to fill the void and provide what was initially a less robust offering, but that suited the basic needs of small clients via workflow automation and centralized TM. These technology vendors responded quickly to user feature requests while big players in translation technology catered mainly to the needs of their large clients and their existing processes. This is a textbook example of an environment that fosters disruptive innovation. What exactly is disruptive innovation? Consider this definition from the Harvard Business Review:
… “Disruption” describes a process whereby a smaller company with fewer resources is able to successfully challenge established incumbent businesses. Specifically, as incumbents focus on improving their products and services for their most demanding (and usually most profitable) customers, they exceed the needs of some segments and ignore the needs of others. Entrants that prove disruptive begin by successfully targeting those overlooked segments, gaining a foothold by delivering more-suitable functionality—frequently at a lower price. Incumbents, chasing higher profitability in more-demanding segments, tend not to respond vigorously. Entrants then move upmarket, delivering the performance that incumbents’ mainstream customers require, while preserving the advantages that drove their early success. When mainstream customers start adopting the entrants’ offerings in volume, disruption has occurred.
Fast-forward another handful of years and some of the SaaS TMS alternatives have been around for many years, are now mature, and offer flexible, cutting-edge solutions. Agile methodologies were employed in their design and the resulting solutions offer a high level of flexibility, some at a staggeringly low cost. SaaS stands for Software as a Service, and refers to a software licensing and delivery model in which the software is centrally hosted and typically consumed through a thin web client on a pay-per-use basis. Maintenance and upgrades are the responsibility of the provider and do not incur additional fees. There is typically one cloud version available to all customers operating off common code, minimizing the overhead required for the provider to maintain and upgrade the software. The existence of one single version in the wild also eliminates the pain of compatibility issues for its users. Agile refers to a now common methodology used in software development, in which an iterative approach is taken that allows teams to both recalibrate and release new features frequently.
The agile development methodology combined with the SaaS delivery model results in a service that is updated with new features at a relatively fast pace. This model has also resulted in superb support for client-side localization teams who are working in Agile environments. The adoption of Agile has been an interesting challenge to everyone in the localization industry, since it produces small incremental translation drops with quick turnaround times, and some tools offer elegant solutions in this realm. Pricing for small incremental translation is another matter that LSPs and clients have to contend with, but having the right tools alleviates some of the pain.
Some of the small TMS technology vendors are now poised to disrupt the enterprise market and are arguably already doing so. There are now solutions on offer that are every bit as robust as the incumbent enterprise-level technology vendors, and at a fraction of the cost with little to no commitment. So why isn’t everyone using these new, flexible, innovative and inexpensive solutions? There are several determining factors.
• Early adopters of TMS (“big ticket” clients who could afford TMS in the early days) are in some cases so deeply entrenched in their existing systems that they do not consider alternatives. Processes and tooling from many different areas in the company that can include marketing, software development, software documentation, legal and internal communications are built around the existing solution. Adopting a new solution would require a great effort involving coordination across many stakeholders within the company. These clients are not likely to disrupt current processes until there is a pressing need that justifies the broad impact of such a move.
• Migration of TM from one tool to another historically is known to incur TM leverage loss, which equates to money. But the new reality is, in the modern days of technology, content is generally structured, making it easier to manipulate without linguistic intervention, and leverage loss can be mitigated by experienced localization engineers. Certainly any software files containing unique string identifiers (which is generally the norm) can easily be aligned and imported to a brand new TM in a new solution with zero loss (in some cases even improving leverage, but that is a separate subject), in which case old TMs can be discarded or kept around purely for backup or leveraging purposes, but remain static (never updated) and can be slowly deprecated.
• Users have developed a hard-earned expertise in their tools and are reluctant or even resistant to change. The greater the flexibility within a new tool, the larger the learning curve. Everyone must be trained in the new tool, including system admins, vendor PMs and translators. For translators who are paid by the word, not by the hour, this equates to a loss in productivity, and therefore dollars.
A new reality in TMS
It’s easier than ever before to adopt or migrate to a new translation technology, including at the enterprise level. Some technology vendors offer solutions based on concurrent licenses, allowing unlimited throughput, which is cost-effective for any client looking for scalability (both upward and downward). Road-maps are determined, not just by large clients, but by input from both large and small users. Pricing is no longer solely negotiated on a case-by-case basis, but is in some of the new pricing models determined by set criteria that is posted openly online. There is, in at least some cases, zero obligation as users can pay month-to-month. This minimizes the amount of time needed for price negotiation and procurement, and pilot projects can be run with very little financial investment. The level of support provided by some of the small vendors is absolutely outstanding, and the new reality is, if there is a new feature you want, in this day and age you can purchase it for a fraction of the cost you might expect or just wait (or perhaps beg your friendly salesperson) because if it is a common issue it’s probably already in a road-map and soon to be available in one of the frequent updates allowed by the combination of a SaaS delivery model together with an agile development approach.