In the last blog we learned about setting alarm thresholds across a localization supply chain, which warns us when a process has failed and a problem must be fixed immediately. But before you get to this point, wouldn’t it be better to identify potential problem areas and work on them before there is a system failure? This is where a data-driven localization strategy can help.
Before we look at setting alert thresholds, it’s important to understand how they differ from alarm thresholds:
- Alarm thresholds are set by hard rules: a contract condition hasn’t been met, or a pre-defined failure rate has been met. Alert thresholds are more subjective. They are defined numbers that suggest there may be problem. Often an alert threshold is set as a percentage below the KPI. It could also be a percentage above the alarm threshold. For example, an alert threshold might be:
- If the result is 15% below the KPI. A number missing the KPI by that much might indicate a problem.
- If a result is only 2% higher than the alarm threshold. This number is getting dangerously close to the alarm level and should be investigated.
- Remember – when an alert threshold is trigged, it indicates that there may be a problem, not that there is a problem. It is not uncommon to investigate an alert threshold only to discover that everything is working perfectly, but there was an anomaly that trigged the alert.
And sometimes alert thresholds are not defined, but instead triggered by the observation of a trend. To illustrate this, let’s look at the on-time delivery chart from the alarm threshold blog.
|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|
Notice the trend in the quality index. Even though the number is consistently above the KPI, each month the index has been getting lower. This trend might trigger an alert threshold as the regular decline could suggest that some process along the content supply chain is causing the quality of translations to drop.
When an alert threshold is triggered, you treat it identically to the way you treat an alarm threshold: you, once again, become a data detective and dig deep into the data of sub-processes to identify what caused the trigger. The biggest difference is, as I mentioned above, there may not actually be a problem.
There may be something going on that is not a process issue, but something unique happening right now that will not continue. In the example above, we might find that the quality index is going down because of an increase in questions going to the customer from translators. But upon further investigation, you might discover some new translators working on the project who are not as familiar with unique requirements of the customer’s content. Once the translator has worked with the brand’s content more, then the number of questions will reduce and the quality will go up over time.
Alert thresholds are among the most valuable benefits of a data-driven localization strategy. Identifying problems, and fixing them before a process failure, can save substantial time, money and resources.
To summarize what we have learned so far:
- Better decisions on your localization process can be made by using data, rather than basing them on perception
- You have access to lots of data through your localization technology tools, internal systems and information from your Localization Service Provider
- Data has to be viewed in context to be useful. That is why you have to track and/or define
- Baseline data
- Key Performance Indicators (KPIs)
- Alarm thresholds
- Alert thresholds
If you’d like to read my final blog, which helps you get started on your data-driven localization process, then please click here.