Companies adopt a translation management system (TMS) to address an array of challenges, but the selection process can be challenging in itself. It generally involves developing selection criteria, making a shortlist, identifying best-fit solutions using weighted business and technical requirements, and undergoing a proof-of-concept before making a final decision. This article provides a simple ten-step model for language service providers (LSPs) to use when selecting technology vendors for shortlisting.
Create a shortlist of available technology choices
Companies need to eliminate choices that do not match the basic criteria in their business or technical requirements. In 2010, we visited or interviewed 31 companies based in 16 countries and devised a rubric for classifying styles of technology adoption among technology-savvy LSPs. We determined that what distinguishes an LSP as being “technology-savvy” is not the style or where it sits on the adoption continuum, but rather how closely its adoption style matches the business strategy of the company and by extension the interests and proclivities of its owners or operators. TMS selection by LSPs should start with a frank assessment of the organization’s technology adoption style based on the tech-savvy typology. To challenge any assumptions about where your company sits in the typology, we suggest the following exercise: Select the base-level paradigm below that best characterizes your ideal market positioning as a tech-savvy LSP.
Paradigm A: Automation within our proprietary production environment is vital. In this archetype, viewing process and efficiency as internal issues for your company has led to a singular, hyper-efficient production model. Companies of this type build a unified system for producing all client work — a single conveyor-belt that delivers superior results as measured by price and volume.
Paradigm B: No qualms about customizing for specific client requirements. At your company, the idea of process efficiency applies at the client or project level. Your company views each customer as unique and deserving a customized solution. Your company has no interest in being a price leader, seeking instead a premium for value-added operations. Big projects and large customers are the norm for your company, and the goal of automation is to advance efficiency in the client environment.
Paradigm C: Can’t we just agree on a single toolset? Your company makes no distinction between client and LSP production environments, seeking instead a limited number of tools that work efficiently with the maximum number of client opportunities. In fact, your company would prefer if the technology question would just disappear. Who cares? Your company wants to be an LSP, not an IT services firm.
Here is how the typology will affect your company’s TMS selection (Figure 1): If you wholeheartedly embrace Paradigm A, your company will be building your own TMS — not selecting a commercial TMS. Dream Machine Builders may consider but rarely adopt specific components into an otherwise proprietary stack. Technology is your company’s differentiator, so it can’t justify buying a commercial system used by other LSPs.
If your company falls between Paradigm A and Paradigm B, you may be a Super Servicer. Your company is happy to buy individual components as long as they serve their purpose and integrate seamlessly with existing components. As comprehensive TMS solutions improve, consider whether adoption of a commercial system could reduce costs without loss of productivity. Consider solutions that would improve the speed of integration with client systems.
If your company fits Paradigm B like the proverbial glove, then it won’t be looking for a single TMS. Your company may already have several. Your company may be tempted by ideas such as federation (“one TMS to rule them all”), but interoperability issues argue against that. Assiduous Assemblers should eventually expect to replace proprietary business information management modules with commercial business-oriented TMS solutions.
If your company can relate to both Paradigm B and Paradigm C, it is a prime candidate for adopting a TMS. The problem is, which one? Unlike Off-the-Rack Operators, Smart Shoppers want to demonstrate competence in multiple systems. On the other hand, they aren’t willing, like Assiduous Assemblers, to buy a new system for every pretty client that waltzes in the door. We recommend distinguishing the business information management from language processing needs.
If your company is on board with Paradigm C, it should choose a single system that works for all its clients. Traditionally, this meant buying Trados licenses and managing your company with Excel spreadsheets. Today, companies are more likely to adopt a business-oriented TMS to replace the spreadsheets. And while many still opt for SDL Trados, increasingly we see Off-the-Rack Operators looking at language-oriented TMS, and especially cloud-based solutions.
Your second step is to decide on a translation management orientation. To make a shortlist, first determine which orientation your company needs (Table 1). If your company already has adequate coverage for either business information management or for language processing from your existing systems, then look for systems with the other orientation. If your company is looking to beef up its capabilities in both areas at the same time, then your company should be shortlisting comprehensive solutions (Table 2). An alternative is to look for matchups that pair complementary systems with different orientations. Business or language orientation options are point solutions, in this context.
Step three is to choose between best-of-breed and comprehensive solutions. There is an age-old argument about whether it’s best to string together a set of point solutions for specific functions, or adopt a unified platform that already has multiple functions pre-integrated. There is no one answer beyond the classic “it depends.”
LSPs face significant risk in swapping out their business information system, upon which they conduct the day-to-day operations of running their company. Adopting a comprehensive TMS pushes this risk into the red zone because the production model is now also affected. We recommend that LSPs opt for point solutions so that they can replace one piece while other keeps going in business-as-usual mode. To adopt a comprehensive TMS, treat it first as a point solution on the language side and fold in the business modules gradually after the production line is up and running smoothly.
Unless your company has development resources waiting around for something to do, the expense and headache of marshaling the resources required to integrate and maintain point solutions will be an issue. The cost of integration and maintenance is justified when the point solutions are a “best-fit” for your organization or, as noted above, to avoid undue business risk. We recommend adopting a comprehensive solution for organizations with constrained resources.
Comprehensive systems come with unified reporting, at least in theory. First-time adopters may have fuzzy requirements in this area, but for advanced users the analytical and business process management functions of a single end-to-end system create a notable benefit.
Step four is to list your cloud options and understand them. Cloud entrants now include LSP.net, Text United, Atelier Concicialitá and Wordbee. Meanwhile, the existing players in the market have learned to sell their wares using cloud-related buzzwords. Most vendors now offer hosted, software-as-a-service (SaaS) or cloud-architected variants. Because cloud can mean many things, here are the variants as we define them:
Hosted. We use this word to designate dedicated instances located at and managed in a remote data center operated by the vendor or a third party where the buyer has purchased the software.
SaaS. We use this acronym to designate dedicated instances hosted in a remote data center operated by the vendor or a third party where the buyer rents the software, paying by the month or through usage charges. SaaS may be single tenancy (a dedicated instance of the software) or multi-tenancy (a shared application instance but typically with secure, segregated data).
Public cloud. In this model, cloud-ready software is purchased but deployed into a public cloud, such as the Amazon Elastic Compute Cloud (EC2).
Private cloud. In this model, cloud-ready software is purchased and deployed into a private cloud, operated on premise or through a third party.
There are variations of all of these models, but buyers should be prepared to decide among these four approaches before establishing their shortlist. Of course, good old-fashioned on-premise installations are still an important option for companies with existing IT resources ready and willing to manage a new piece of complex software.
Future-proof your selection
During the requirements definition phase, perhaps the most challenging aspect is to identify and assess future needs. What follows is an assembly — no doubt incomplete — of some of the hot issues that buyers should be sure to account for in their planning documents. In addition to quantifying reuse, buyers should also benchmark systems for performance — size of memories, processing times, and throughput for various content and file types. As we suggested in our most recent report on machine translation (MT), planners should also imagine radical growth as throughput often doubles every 18 to 24 months.
Step five is to insist on interoperability. All TMS shoppers should aggressively pursue the issue of interoperability. Translation supply chains represent an exceedingly heterogeneous operating environment. Any TMS buyer could reasonably expect that downstream partners may use a variety of translation environments requiring slightly different pre-packaging of project files. Ideally then, the TMS your company purchases would exchange project data and content with other TMSs. Buyers must start demanding this capability. Today, the most you can expect is the ability to prepare files for processing by multiple toolsets.
Companies buying a TMS can also reduce or eliminate one of the biggest challenges of translation management and organizational transformation–mergers and acquisitions. For LSPs and translation buyers alike, when that moment arrives for buying or getting bought by another company, interoperability at the TMS level will soften what is otherwise a potential train wreck.
In the sixth step you should plan for hyper-utility of linguistic assets. In addition to pre- and post-processing to prepare files for translation or for delivery to the client, the centralized TM modules will soon be expected to include tools for scrubbing and purging memories, and also for selecting subcorpora for the purpose of training project or product line-specific MT engines.
TMS deployments increasingly combine translation memory (TM) and terminology management with MT so that segments not matched in the TM can be routed for pretranslation in MT. This technique replaces every segment during pretranslation, thereby leaving no source language content except for reference purposes.
In the seventh step you should learn from the companies that have gone before you. Talk to other practitioners about what they’ve experienced since their initial deployments. Here are some of the things we hear when we ask, “What do you wish someone had told you beforehand?”
Once the system is up and running, your company will want to bring in more groups, offices, departments and business units, so look at the acceptability to new groups. Will your system be adequate for those needs? When a single department adopts a technology, there is no corporate mandate, and there will be potentially insufficient funding to encompass the needs of the entire organization. This can lead to the selection of departmental solutions that won’t scale, causing pain and frustration later. You should also look at adaptability with new systems. Planners must think about what’s in the pipeline and what industry trends might indicate for future investment. Take advantage of industry research to learn where the market is going.
For LSPs, the jumble of systems and work methods makes reporting a time-consuming activity forcing a bare-bones approach. For enterprises the lack of a system today means reliance on what suppliers tell you. TMS opens access to data that executives will start asking for, and your company will want to provide as evidence of your team’s effective management. Plan for this by anticipating new reporting demands.
Completing the process
So, your company has determined the type of system you are looking for, organized your business requirements, checked with IT for technical requirements, and made your shortlist. What’s next? Every organization may have specific technology selection procedures, but here is what you can expect, in general.
Step eight is to weight your selection criteria. The more detail in your criteria, the better, at least to start with. After completing the collection phase, the winnowing begins. At this stage, combine and compress the descriptions as much as possible. The tighter your descriptions and the more crystallized the thinking gets, the easier it will be to prioritize. Vaguely worded and overlapping requirements will get you nowhere. Initially, divide things into three categories:
Must-have: Limit the show-stopping must-haves to as small a number as possible. These are critical requirements that preclude any system that cannot meet a single must-have item. This list has to be tiny. After the first pass at prioritization, you may start with 20 or 30 items here. Move most of them into the “Need-to-have” category.
Need-to-have: This is the category you will assign the weighting to. Keep it as small as possible. Most of the items you start with here should be pushed down to nice-to-have, in order to make room for the things individual stakeholders claim are must-haves for them. Ideally, you can keep the actual weighting to about 30 items.
Nice-to-have: These are all the remaining needs that it would be really cool if the system can do it. Realize that if you do a good job with the must-have and the need-to-have categories, you’ll end up with a system that in fact takes care of many of these items. Don’t clutter up the weighting by trying to include them all. It only defocuses your process and makes the decision less obvious.
Step nine is to choose one or both proof-of-concept models. There are two approaches to proof-of-concept testing, and we recommend doing both. First is the proof-of-concept demo. Invite the top three scoring vendors to present their solutions in person after giving them your detailed requirements. Ideally, this is a live demo using your actual content samples. The second is piloting. When it’s feasible, progress to using the best-fit system for a live project. This will require dedicating resources and may involve extra costs. The payoff is a deeper understanding of how the system performs and, more importantly, how your team responds to the particulars of one or more systems in a production context.
The final step is to calculate the total cost of ownership. Consider the three-to five-year cost of licensing and maintenance, infrastructure for on-premise deployment, customization and integration services, training, plus internal tariffs for IT resources and administration.
By shortlisting properly and future-proofing your requirements, your com- pany will only have best-suited applications in your final pool of candidates, and the chances of making a mistake will be greatly reduced. But don’t be shy about asking for assistance from your peers and industry experts wherever you find them. More opinions in this case will likely mean better opinions for your company to choose from.
