Simultaneous shipment ("sim ship") of all language versions of a product is an ideal that few companies actually achieve. In this article Tony Gray of Oracle describes the results of a project to improve Oracle's sim ship capabilities that has allowed Oracle to consistently deliver products in thirty languages at the same time. The key? Support from senior management and building the right team.

 

The project kicked off in early 2001. Adoption of the Oracle E-Business suite was taking off and Oracle was accelerating product and functional enhancement roll out. The suite had broadened to include Financials, CRM, Supply Chain, Manufacturing, HR products and more. It required translation of approximately 4 million words of software strings into 30 languages.

It was becoming obvious that our existing translation solutions could not scale to meet the demands of the business. This was apparent in our inability to sim-ship language releases. In fact we were going backwards in terms of closing the delta. Senior management viewed this as critical to the success of the E-Business suite internationally. The re-engineering project was made a top priority for a number of departments involved in delivering the new solution.

One of the key success factors was pulling the right people together into a virtual team. This included participants from product development, localization and IT teams. We also pulled in an Oracle corporate architect to validate the approach and solution design. In practical terms, this meant numerous scheduled conference calls per week and many impromptu calls. These calls covered technical aspects of the project up to senior management status review. For the duration of the project, team members in Europe were available 24 hours a day, 7 days a week in order to facilitate effective teamwork with our US colleagues.

Making the shift

In the old model, we would run two or three large projects every year, each up to four months' duration. Today, we localize content as soon as it is created. We provide our vendors with a translation queue, which is updated 24 hours a day. They log on to our system several times a day and can see what work is queued to them with related wordcounts. We have agreements worked out with them to manage turnaround and quality expectations.

The change process with the vendors wasn't always smooth. Particularly in the early days we didn't have all the answers about how we were going to manage the process. It's largely thanks to the flexibility and commitment of our vendors that we succeeded. Recent feedback from our vendors has been extremely positive. They like the predictability of a constant flow of work.

In the past, we have tended to work with a mix of MLVs and SLVs selected based on their in-country capability. Where we worked with MLVs we used to deal with their central organizations. However, we have found that because our new model is so automated and it leverages the Internet, that the central MLV organizations became a bottleneck. So today, for all operational parts of our business, we go directly to the in-country translation teams, even if they are part of an MLV. We use the central MLV organization for contracts, escalations, strategy discussions and so on.

The entire re-engineering project took approximately two years. However, we focused on quick wins early on. Within six months, we had achieved our goal of sim-shipping the E-Business suite in all thirty languages. It took us about another six to eight months to get translation truly in synch with the development process. The last six months of the project was adding value add functionality such as metrics gathering. The most challenging part of the project was managing people and organizations through change. A large number of people from developers through localization engineers, project managers and vendor staff were impacted.

We are currently starting a project to implement this solution for product documentation. Beyond that, there are no immediate plans for further use. But, you never know.

Standards and Technology

The initial focus on the re-engineering project was on translation infrastructure rather than any specific language technologies. This included creation of a central database repository of all translated strings, all processes to be managed by workflow and enterprise enabled using the Internet.

There are two areas where language technologies are deployed in the infrastructure. Both of these are developed by Oracle. Internally, we manage the repository of translated strings and use this for string matching. This includes functionality for managing the repository such as fixing incorrect strings, searching, sorting etc for reference work. External to Oracle, we supply the vendors with a translation tool.

One of the goals of the project was to move towards common localization industry standards. Now that the right infrastructure is in place, we are introducing XLIFF as our interchange format. This will open up the possibility of integrating other language technologies into the overall solution. For example, the vendors will have the option of translating using an XLIFF editor of their choice.

Cost and ROI

Over the two years, I would estimate Oracle's total investment in the new infrastructure to be on the order of $1.5 million. We didn't go through an elaborate justification process before the project started. It was accepted that this wasn't optional, we needed it to support the business.

This investment has resulted in internal headcount savings of approximately $1 million per year. So, we have a positive ROI within 2 years. We also experienced no cost increases from doing localization work concurrently with English development effort. In fact, we are finding that it is actually lower cost to localize concurrently with development. Some examples of this reduction are:

• Having a 100% automated process ensures that we have minimized the number of internal engineering resources required (from twenty engineers down to two). For example, we estimate that our engineers spent 50% of their time in the past dealing with inefficiencies and rework caused by poor enforcement of standards at source in development. With the automated system, a developer will get feedback within minutes if they check in code that cannot be internationalized.
• Because our relationship with our vendors is now completely automated, we have also reduced our internal project management overheads. The number of project managers required to manage day-to-day vendor operations has been reduced from five to one.
• Volumes for translation temporarily increased during the period where we closed the gap to synchronize development and translation. However, now that this is done our external vendor spend is much easier to manager. Previously, our spending spiked two or three times per year with each large project. This is difficult to manage from a budgetary point of view. Today, we have more or less constant quarterly spending.
• We have increased the number of resources working on product QA. However, because we are testing the international versions before the US product releases, our success rate in fixing bugs has improved considerably, so overall the ROI on QA has improved. This obviously results in a better product for our customers.

It is almost impossible to quantify any increase in international product license revenue directly due to simultaneous shipment (if anyone out there has figured out how, then I'd love to hear from you). Hypothetically, if you estimate that your international products account for 30% of your revenue, then a delay of one financial quarter is impacting approximately 7.5% of your revenue. If your business is growing at 20% per year, then you could hypothesize that the delay of one quarter has knocked 1.5% off your growth rate.

 

---

---

---

Submit your article!

Read more articles - free!

Read sense of life articles!

E-mail this article to your colleague!

Need more translation jobs? Click here!

Translation agencies are welcome to register here - Free!

Freelance translators are welcome to register here - Free!