0
Answered

How can I set up a process template that has different processes?

Jaime Zuniga 3 years ago updated by mark 3 years ago 9

Consider the following scenario:

We receive 3 files to be translated into 2 languages. One language, Spanish for instance, has to translate all 3 files, while German, the other language, only needs to translate 2 of the 3 files, and also needs a Client Review step. The languages may or may not be the same every time.


I read up on your forking (subprocesses) documentation but I did not see a way of doing this for the above scenario. Maybe it would involve splitting?


Thanks,

Jaime

Answer

Answer
Answered

At the moment, Smart Projects should be thought of as single-process projects.

So, leaving forked processes aside, there are two ways to go with a need for a multi-process request:

  1. One was already mentioned by Sancho: create a template with longer process and skip certain jobs for some languages in an actual project.
  2. Another one would be creating two projects in XTRF with the same uber-project ID (think custom field here) but each of them running on a different process. You can invoice multiple projects at once and that ID would help you do that.

I would be interested in learning best practices for this as well. Currently what we would do is use our standard translation process. We'd split the job into two languages. Then the PM would manually remove access to the Spanish-Only from the German translator and German editor. Doesn't seem like an elegant solution, but that's what we'd do. I do wonder if there is a more straightforward way.

Forking would be the answer, but we burned out fingers with it in the past, especially when you design long processes. We have thus opted to pick the longest applicable process for all languages and then cancel the unnecessary jobs per language, i.e. in your case use the full-length process including Client Review for all languages and then cancel Client Review for the languages it is not necessary for. Different file management is best handled as described by Mark.


I do hope the process forking will be more reliable in the future, or better yet, the project folder approach XTRF has hinted at will allow for greater flexibility within the overall project.

Searching answer

Forking is based on the idea that certain sub-set of languages always follows a path that the other languages should not. We added it in its very basic form to see what other needs it raises. Thanks for your input, Jaime.


As the feature is considered experimental, there surely is place for extending its functionality to include more conditions and serve a wider scope of scenarios. Feel free to start a new topic on the Ideas forum to discuss the potential developments.

I would love to hear from XTRF people regarding their best practices and if they have best use guides that would help us create processes more efficiently and that are based on how the system is designed to be used. Currently, it feels that we are making our processes up as we go along. Having said that, it's good to hear from Sancho that what we've decided to do for file management makes sense to him.

+2

@ Mark: I echo your sentiments.

@ XTRF: Do you have some "optimal" XTRF Smart Project process design samples including live case examples to see how such processes will work in real operations? It is great that XTRF provides flexibility, but it makes perfect sense for XTRF to present best practices, based on how the system was designed to work optimally.

Yes, "best practice" workflows would help a lot.

Answer
Answered

At the moment, Smart Projects should be thought of as single-process projects.

So, leaving forked processes aside, there are two ways to go with a need for a multi-process request:

  1. One was already mentioned by Sancho: create a template with longer process and skip certain jobs for some languages in an actual project.
  2. Another one would be creating two projects in XTRF with the same uber-project ID (think custom field here) but each of them running on a different process. You can invoice multiple projects at once and that ID would help you do that.

We do use both approaches, and while it is a temporary workaround until we see improvements in the multibatch/subproject management in Smart Projects, it allows you to run your business. We use a customer field called "Master project ID" on project level to be able to gather all individual projects (and underlying tasks) at the invoice creation stage. Having said that, it makes automatic invoicing less practical because of having to decide on the proper sorting of individual projects/tasks included in the overall master project invoice.

We are planning on using both for different purposes. The longer process approach is used for complex projects where we don't want PMs to have to create their own processes, but scaling back an existing project is adequate. And for batch projects or for multiple source language projects, using the custom field to group the projects is the direction where we're going. 


In our case, that will work for us with the invoices. We worked with XTRF to create invoice templates where the summary is based on projects rather than tasks. The only issue is we'll need to standardize our project naming structure for projects that are batched in this way.