Un SLA qui veut dire quelque chose
Un SLA dans Tasked correspond à un nombre d'heures sur une étape. Lorsqu'une tâche entre dans l'étape, un chronomètre se lance : la tâche est correcte jusqu'à ce que 80 % des heures se soient écoulées, à risque ensuite jusqu'à la date limite, et dépassée après celle-ci. Pour les validations client, un processus s'exécute toutes les 15 minutes et relance la personne dont la validation est attendue, avec un intervalle de 12 heures entre chaque relance, et chaque relance est enregistrée dans le journal d'audit.
Heures par étape, définies dans le modèle
Chaque étape d'un modèle de workflow peut comporter des heures de SLA. Le pack publicité est livré avec 48 heures sur le Brief, 72 sur le Script, 48 sur la Validation du script, 120 sur la Pré-production, 48 sur le Tournage, 120 sur le Montage, 48 sur la Review du rough cut, 72 sur la Validation du final cut et 24 sur la Livraison. Ce sont des valeurs de départ, et le forfait les décrit comme telles : un SLA de validation de 48 heures est un chiffre du modèle, pas une réalité concernant vos clients.
Un nouveau projet copie le modèle, de sorte que ses étapes comportent les heures que le modèle avait ce jour-là. Modifier le modèle modifie les projets futurs ; modifier un tableau en cours est une étape distincte, par projet, ce qui évite qu'une modification de SLA en direct ne réétiquette discrètement le travail déjà en cours.
Trois états, calculés et jamais stockés
L'état d'une tâche par rapport au SLA de son étape découle de trois moments : quand elle est entrée dans l'étape, quand tombe l'échéance du SLA, et maintenant. Rien n'est écrit sur la tâche lorsqu'elle franchit une limite, il n'y a donc pas de balayage en arrière-plan qui pourrait prendre du retard et afficher une tâche comme correcte une heure après son dépassement.
- Correct : moins de 80 % de la fenêtre s'est écoulée.
- À risque : 80 % ou plus s'est écoulé et la date limite n'est pas dépassée.
- Dépassé : la date limite est passée.
- Une étape sans heures de SLA est toujours correcte.
Ce que fait un dépassement sur une validation
Pour les validations, le produit fait bien plus que simplement colorer une carte. Une tâche planifiée s'exécute toutes les 15 minutes, examine les validations en attente par organisation, et pour chacune d'elles ayant dépassé sa fenêtre, envoie la même relance auditée qu'un producteur enverrait manuellement.
La relance est envoyée à la personne dont la validation est attendue. Pour une validation destinée à un client, il s'agit de l'accès au portail client du client : le code, le lien, le téléphone ou l'e-mail par lequel il a été invité. Pour une validation interne, il s'agit des responsables de la tâche. Une relance n'est jamais envoyée deux fois en l'espace de 12 heures pour la même validation, et le processus envoie au maximum 50 relances par organisation et par exécution, afin qu'un studio qui reprend après deux semaines de fermeture ne soit pas submergé dès le premier matin.
Chaque relance marque la validation avec l'heure à laquelle elle a été envoyée et enregistre un événement d'audit. Le producteur peut également envoyer la relance manuellement depuis la validation, selon la même règle des 12 heures, et cela fait aussi l'objet d'un audit.
Le chronomètre démarre à la demande
Le chronomètre du SLA d'une validation démarre lorsque la validation est demandée, et non à la date d'échéance qu'un producteur aurait pu saisir. La date d'échéance est une promesse faite au client ; le SLA est une mesure du comportement du client. Un SLA de 48 heures dépassé au troisième jour est un fait, peu importe ce que disait le calendrier, et la relance se déclenche sur la base de ce fait.
Les intervalles qui alimentent les analyses mémorisent les heures de SLA en vigueur lorsque la tâche est entrée dans l'étape, de sorte qu'une correction ultérieure ne transforme pas une tâche réalisée dans les temps en une tâche dépassée dans l'historique.
Ce que le SLA alimente
Le SLA n'est pas seulement une relance. Trois autres parties du produit le lisent. L'audit de processus compte, par étape, le nombre d'intervalles enregistrés qui ont duré plus longtemps que les heures de SLA, et ce nombre de dépassements est le chiffre par rapport auquel une proposition de correction est simulée. Le score de risque ajoute 10 points à un projet dont une validation est en attente depuis plus de trois jours. Les vues portefeuille et client totalisent les minutes passées à attendre les clients lors des étapes de validation.
Un SLA erroné n'est donc pas un problème esthétique. Il produit de faux dépassements dans l'audit, une fausse urgence dans les relances et une image faussée des clients qui sont lents.
Choisir des heures qui veulent dire quelque chose
Définissez les heures que vous attendez réellement, puis mesurez pendant un mois. La vue des goulots d'étranglement donne le temps médian dans chaque étape, et l'audit de processus le compare à ce que vous avez défini. Là où la médiane est bien supérieure au SLA, l'audit propose une correction ; là où une étape n'a pas encore de SLA, la proposition est de la mesurer avant d'en définir un.
Un SLA dépassé pour la moitié des tâches n'est pas un SLA, c'est un vœu pieux. Un SLA dont personne n'atteint jamais les 80 % ne sert à rien non plus. Celui qui se situe entre les deux est celui qui veut dire quelque chose.
Questions fréquentes
- Quand une tâche devient-elle à risque ?
- Lorsque 80 % des heures de SLA de l'étape se sont écoulées depuis que la tâche est entrée dans l'étape. Elle est dépassée une fois la totalité des heures passée.
- Qui reçoit la relance en cas de validation dépassée ?
- La personne dont la validation est attendue : l'accès au portail client du client pour une validation client, les responsables de la tâche pour une validation interne.
- À fréquence une relance peut-elle être envoyée ?
- Au maximum une fois toutes les 12 heures par validation, qu'elle soit envoyée par le processus ou par une personne. Le processus envoie également au maximum 50 relances par organisation et par exécution.
- Le fait de modifier un SLA réécrit-il les dépassements passés ?
- Non. Chaque intervalle enregistré conserve les heures de SLA qui étaient en vigueur lorsqu'il a commencé, de sorte que l'historique est rapporté selon la règle qui s'appliquait à ce moment-là.