Finding the right TMS - how hard can it be?

Berlin-based LSP, text & form, was faced with exactly this dilemma. The costs associated with maintaining and extending their proprietary TMS solution were substantial, yet the list of desired functionalities continued to grow. The real question came down to one of return on investment: did the proprietary system create competitive advantages that would justify the additional investment, or would it be more cost-effective to invest in third party solutions? We chose the latter course, and this is our story.

You are here

The first thing you need to know when planning a journey is where you are starting from. This is often more important than where you are going, because it is possible to alter your destination en route. At text & form, we began with a thorough assessment of the existing proprietary technology. In performing this assessment, we looked at three broad questions:

• How well does the system support our day-to-day business needs?
• Is the system designed in such a way that we can easily add new features and integrate with external systems as necessary?
• What level of staffing support is necessary to maintain and extend the system?

Armed with this information, we then made a brief survey of available third party options with the following questions in mind:

• Where can we expect improved process automation from a third party system?
• What kinds of process changes will we need to make to adapt to a third party system?
• What level of investment in licensing and maintenance fees are required for a third party system?

Before moving to a “build/buy decision”, though, it was necessary to look carefully at our real business requirements. Too often, these “requirements” are simply derived from current processes, forgetting that the processes themselves often have their roots in a possibly inadequate technological environment. In this case, we put together a relatively short, high-level description of what we needed to run the business more efficiently. This included requirements for improved financial reporting, improved visibility into costs incurred for various types of projects, improved automation of repetitive tasks, improved ability to integrate with external partners and improved support for collaborative workflows.

After performing a gap analysis based on this requirements document, we eventually decided that moving to a third party solution was the best choice. The key factor in that decision was the recognition that technology is changing the business environment, and the ability to integrate with external systems and to support collaborative approaches to delivering language services was essential. Sharing the cost of that capability set with other customers was the obvious financial choice.

Making the selection

Having laid the groundwork above, we were now ready to look at options. All the demos really do look good, so the key at this point is to consider the available features in light of the specific requirements of your business. The demos will typically focus on one or two “standard” processes and amaze you with how easy it is to use the system for those processes. There are three ways this can be misleading.

First, the language services business is a lot more diverse than is commonly recognized. Processes that make sense for one segment of the market may not be appropriate for another. These hidden assumptions about process are built into the way prices are handled in the system, the way workflow is automated and the way resources are assigned to tasks. It is important to consider the system capabilities in light of the details and variety of your processes and not rely totally on the vendor.

Second, most or all of the tools on the market provide capability for the “traditional” localization projects. Support for stream-oriented translation processing (such as might occur in a user-generated content environment), collaborative workflows, agile localization, multi-media localization, etc. is rare and often immature. Here it is important to look at where your business is going, not where it has been when evaluating options.

And third, it is important to look at the “master data” the system requires in order to make the actual project management go so smoothly. How is it organized? How easy is it to change if needed? How are more complex situations handled? One thing is certain: the way you are organizing your master data now is probably not going to fit into the new system. At text & form, we have found that reorganizing our approach to this data has some benefits, but it certainly comes at a cost.

The only way to really evaluate the degree to which these three areas impact your business is to do some detailed pilot testing. This is often very expensive in terms of staff time, but the alternative is to discover too late in the process that “things just don’t work”. At text & form, we narrowed it down to three options during our initial screening, and then did our pilot testing sequentially. In other words, we gave our first choice an opportunity to prove itself, and moved on to the second choice only after determining that the first choice would not meet our needs. In our case, we were guided in part by the preferences of our key customers in determining the priority within the set of potential solutions.
In order to run an effective pilot test, all areas of the system need to be exercised within the context of your range of projects.

This will require substantial investment in training, system set-up and configuration, and actual staff time running different scenarios. In our case, it was only when we delved into the details of our various project types that the shortcomings of our first choice solution became evident. This was not all “lost time”, though, because it forced us to think more carefully about the details of the processes we intended to implement. In fact, generalizing from the lessons learned in “round one”, we were able to come to the conclusion much more quickly that our second choice also fell short of our expectations.

We eventually were able to assure ourselves that our third choice would meet most or all of our needs. The system provided flexibility where we needed it and seemed to be able to accommodate most of the peculiarities of our processes. At this point we also engaged deeply with the vendor organization itself in order to assure ourselves that they would be responsive to our ongoing needs. One of the key advantages of a third party solution is (or should be) the ability of the vendor to aggregate demand from multiple sources and provide new features and functionality at a rate that would not be possible with an internal development team. Too often companies make the mistake of evaluating only the product and not the vendor, which can lead to future disappointments.

Don’t forget the process

In all of the above, it is important to remember that technology alone is not going to solve all the problems. As Ben Sargent (Common Sense Advisory) has recently observed, changing technology without addressing the underlying processes will limit the ROI of any technology investment. At text & form, we tried to keep the future possibilities firmly in mind as we made our final selection. The risk in this, of course, is that some of our “what if” scenarios ended up not being supported in the system we chose. Or at least not supported yet. Managing expectations is an important part of managing a successful technology transition.

From theory to reality

Once the selection is made, the focus shifts to “making it happen”. This involves two components. In the first place, it is important to negotiate a business agreement with the vendor that incorporates any of the promises made during the evaluation process. In our case, there was a short list of “must have” features that the vendor agreed to include in the next release. It was important to have those features documented and included in the contract. Depending on the nature of your specific needs and the vendor’s policy, there may or may not be extra fees involved, and this is another area that has to be addressed explicitly.

In the second place, it is important to plan for the various tasks leading up to deployment. These fall into several categories:

Data migration and configuration

Some of the effort here became evident during the pilot phase, but there is a huge number of details to work out. The new system will always organize some of the master data differently, and there is a lot of work involved in identifying the logical mapping, eliminating duplications or obsolete data, establishing default relationships for data that is not kept in your legacy system, etc. At text & form, we are still in the process of finalizing this step.

Training & communication

During the pilot phase, it is not often feasible to involve all staff and not often advantageous to involve customers or vendors. It is important, however, to be sure that key stakeholders are aware of the process and have an opportunity to contribute. Once the decision is made to proceed with a particular solution, this communication need becomes an even higher priority. At text & form, we began with a comprehensive training program for all project management staff. Project managers were then divided into teams with similar concerns to work out the details of process changes, workflow definition, etc. Most systems allow for at least some variation in areas such as how vendors are selected/assigned to projects, how/when email notifications are sent, etc. In order to benefit fully from the system, it is important to develop processes that take advantage of the full system capabilities.

We also need to communicate effectively with external stakeholders. In our case, we have identified a handful of key customers and will involve them in the final stages of deployment planning. We also plan to communicate in advance with all customers so that changes in the format or frequency of our project-related communications will not come as a surprise. Similarly, the new system will provide substantial benefits to our vendors, especially in the area of managing the business communications (purchase orders, invoices, etc.). It is important to include these stakeholders in the run-up period to final deployment.

Final Deployment

At some point the decision has to be made … to go or not to go (live)? That is the question. It is important to minimize the risk when making the final decision to put the new system into production, but it is also important to acknowledge that there will always be some problems associated with using the new system. In an effort to minimize both the risk and the number of problems, consideration needs to be given to the following questions:

• Have the internal staff been trained on the new system well enough to accomplish their daily tasks?
• Is it possible to run the old and new systems in parallel? Often this is not feasible, but it at least has to be considered.
• Is it possible to move to the new system gradually (by customer or project or project manager)? Again, in many cases this is problematic. For instance, since both the legacy TMS and the new system chosen for text & form handle invoicing, we will need to make a clean break in order to continue the sequential numbering required by German law.
• Is there a deployment support team assembled with both the authority and skills to solve problems that arise?
• Is vendor support available should something unexpected turn up at the last minute?

Lessons learned

At text & form, we are finalizing the answers to these and other more detailed questions as we plan for final deployment later this year. One obvious “lesson learned” is that these kinds of major decisions cannot be easily made or quickly implemented. Moving from an internally developed system, even one that is showing the strains of age, to a third party TMS solution challenges the organization at a number of levels. We have found it challenging to find the staff time to fully evaluate options (whether technological or process). We have also discovered that legacy processes designed to handle specific needs of individual customers or projects are difficult to migrate and adapt to the new environment. And finally, we have learned that some of the most interesting opportunities to automate workflow are still “opportunities” rather than current realities.

The good news, however, is that the new system really does provide those opportunities. It also promises to give us much better insights into the day-to-day activities, both from a customer satisfaction perspective and a financial performance perspective. And having chosen a third party solution allows us to focus our business energies on customer service and language service innovation, rather than on maintaining a proprietary software system.