In my last blog on data-driven localization, I talked about Key Performance Indicators (KPIs). A KPI is your stated goal, and measuring against it allows you to track your level of success. But measuring success is only one of the things you gain from following a data-driven localization process. Data-driven localization can also indicate when there is a problem and ultimately help you fix it.
Not meeting the KPI only indicates you haven’t reached your stated goal, but it isn’t designed to indicate when there is, or may be, a potential problem. That is why you also have to define thresholds, and I want to demonstrate the value of these in meeting goals and expectations.
Let’s begin by using data to analyze delivery times of projects.
On-time delivery is very important in the localization process. One small delay could have a further impact down the translation supply chain. However, deadline extensions on projects are sometimes needed. Many contracts allow the Language Service Provider (LSP) to request an extension on a certain percentage of jobs. Here is a report showing some results of the past three months from a typical company looking at their extension alarms:
|Number of localization jobs||35||20||35||36||39|
|Number of words translated||7,500||6,000||7,500||7,700||7,300|
|LSP extension requests||7%||4%||4%||6%||8%|
|Customer urgent job requests||4||2||4||5||6|
The contract in this example allows the LSP to request an extension on 7% of localization projects. In March, the LSP requested an extension on 8% of the jobs. This triggered the alarm threshold. To figure out what caused the problem we must become “data detectives,” and look at other data sources.
We have to dig down deeper into the data to determine the cause of the problem, otherwise we can’t create a solution to the problem. We also need to carefully look at the underlying process that caused the problem. Is this an isolated instance, or is there a flaw in the process that must be fixed to ensure the problem doesn’t happen again?
Looking at the data above there are a number of factors that may have led to the high number of extension requests:
- More localization jobs were executed in March than any other month.
- Although the quality index remains above the KPI, it has been consistently decreasing.
- The customer requested a large number of urgent job requests, 50% higher than the KPI.
Any, or a combination of, these factors could have caused the problem. Being a data detective means looking at as much data as is necessary to determine what the problem is. That is why I suggest you get as much data as you can on your localization processes.
When an alarm threshold is crossed, it requires immediate action, so alarm thresholds have to be well defined. At a bare minimum, an alarm threshold should be defined any time a contractual obligation hasn’t been met but should be defined at the start of any project. Depending on your reporting system, it should allow you to be automatically notified when an alarm thresholds has been crossed. This can help save substantial costs, and further impact down the translation supply chain.
You can see the importance of alarm thresholds, how they alert you to an existing problem and allow you to fix it. But wouldn’t you like to be informed that there might be a problem so you can fix it before there is a process failure? That is what an alert threshold is, and will be covered in the next blog.
Check out my webinar, Data Drives Desired Decisions, for a detailed example of using KPI’s and thresholds to analyze your data. Or if you’d like to read my next blog on setting alarm thresholds, please click here.