Gérer le départ d’un utilisateur Tableau sans casser le lundi
Une personne s’en va. Son nom reste sur des classeurs, des planifications et des abonnements, et plusieurs d’entre eux tombent en panne sans un bruit. Ce qu’elle détient, ce qui casse, et l’ordre qui garde la licence récupérable.
Le compte est fermé chez le fournisseur d’identité. Le ticket est marqué terminé. Sur le site Tableau, six sortes d’objets portent encore cette personne comme propriétaire. Chacune se comporte différemment une fois que le propriétaire cesse d’être licencié.
Classeur
Il continue de fonctionner. Le propriétaire est parti et personne n’en répond. Les identifiants qui y étaient intégrés étaient les siens.
Source de données publiée
Pareil. Tout ce qui est en aval hérite du problème, et personne n’a choisi cela.
Flux
Il cesse de s’exécuter s’il s’authentifiait en tant que l’utilisateur partant. Les sorties en aval conservent en silence leur dernier résultat.
Projet
Les permissions sont héritées de l’endroit où se trouve le contenu. Un projet sans propriétaire actif laisse le modèle de permissions sans propriétaire actif.
Abonnement
Soit il cesse d’arriver, soit il continue d’arriver, adressé à quelqu’un qui est parti. Les deux sont faux, et un seul se remarque.
Tâche de rafraîchissement
L’extrait cesse de se mettre à jour. Le tableau de bord reste en ligne et devient obsolète sur place.
La dernière est celle qui coûte cher. Rien en elle ne semble anormal.
Les pannes qui restent silencieuses
Classées selon la durée pendant laquelle elles passent généralement inaperçues, la plus longue en premier.
Une tâche de rafraîchissement sans propriétaire actif. Le tableau de bord sert comme il l’a toujours fait. Les données derrière lui prennent un jour de plus chaque jour.
Un abonnement qui envoie encore. Quiconque le reçoit suppose qu’un rapport qui arrive est un rapport que quelqu’un entretient.
Des identifiants intégrés par la personne partie. La connexion continue de fonctionner. Elle s’arrête quand cet identifiant est renouvelé, ou quand le compte est désactivé.
Un flux qui s’est arrêté. Les sources de données qu’il alimentait existent toujours et renvoient toujours des lignes. La panne se trouve à un saut de là où quelqu’un regarde.
Du contenu dans un espace personnel. Personne d’autre ne peut le voir, donc personne d’autre ne peut en hériter.
Décider qui hérite de quoi
La réattribution a l’air technique. C’est une décision métier. Un logiciel peut déplacer la propriété, et seule une personne peut dire où elle doit aller.
Le contenu avec une équipe évidente : donnez-le au responsable actuel de cette équipe, pas à un administrateur.
Le contenu que personne ne réclame : donnez-lui un propriétaire provisoire nommé, et mettez-y une date de revue. Cela diffère la décision sans l’abandonner.
Le contenu dont le seul utilisateur était la personne qui part : archivez-le comme preuve. Le passer à quelqu’un qui ne l’ouvrira jamais n’aide personne.
Un schéma mérite qu’on y résiste : tout déplacer vers la personne qui gère le départ. C’est rapide, et cela semble réversible. Un an plus tard, cela ressemble à n’avoir rien fait.
Cinq risques à voir en premier
Le planificateur trouve ces cinq risques et les montre pendant que le plan est encore en lecture seule. Rien n’a encore changé.
Identifiants intégrés
L’élément s’authentifie en tant que l’utilisateur partant. Déplacer la propriété ne le ré-authentifie pas. Une personne doit fournir un nouvel identifiant.
Rôle incompatible
Le nouveau propriétaire proposé a un rôle de site qui ne peut pas détenir ce contenu. L’exécution s’arrête là, plutôt que de laisser un état à moitié terminé.
Un abonnement sans propriétaire actif
La livraison continue sous un propriétaire qui est parti. Ou elle s’arrête, et les destinataires n’entendent rien.
Une tâche de rafraîchissement sans propriétaire actif
La planification survit à son propriétaire et les données non.
Un déplacement entre projets
L’élément atterrirait dans un autre projet, et les permissions suivent l’endroit où se trouve le contenu. Le déplacement change qui peut le voir.
Les cinq apparaissent dans la phase de plan, qui lit, propose et ne change rien. C’est le moment d’en débattre.
Une seule règle d’ordre
Une seule règle d’ordre porte toute l’opération. L’utilisateur n’est passé en Sans licence qu’après que chaque réattribution a réussi.
L’alternative vaut la peine d’être imaginée. Libérez la licence d’abord, et laissez une réattribution échouer. Du contenu se trouve maintenant sous un compte qui ne peut plus rien posséder. Le récupérer est une conversation avec le support plutôt qu’un clic.
Parfois chaque réattribution réussit et seul le changement final de licence échoue. C’est le bon échec. Le contenu est en sécurité et la licence est toujours détenue. Ce qui reste est une seule action, à prendre à votre rythme.
La séquence
Découvrez tout ce que l’utilisateur possède, dans les six catégories. Une arborescence de projets n’en montre qu’une partie.
Lisez le plan, y compris les risques, avant d’en approuver quoi que ce soit.
Choisissez les nouveaux propriétaires en tant que personnes. Les valeurs par défaut sont la façon dont le contenu finit nulle part.
Approuvez, et laissez la réattribution s’exécuter jusqu’au bout.
Seulement alors, libérez la licence.
Gardez le registre : ce qui a bougé, vers qui, et qui l’a approuvé.
Tout le monde dans la pièce veut récupérer la licence. Elle reste la dernière chose qui doit bouger. Récupérer une licence prend un clic. Récupérer un tableau de bord sans propriétaire actif prend un après-midi et un appel à quelqu’un en vacances.
La vérification à lancer tôt
Chaque élément ci-dessus peut être trouvé pendant que la personne est encore là. C’est le moment le moins cher pour y remédier. Une revue trimestrielle de la propriété prend environ une heure. Elle retire l’essentiel de la surprise de chaque départ qui suit.
Le contenu détenu par des utilisateurs inactifs ou qui ne sont plus licenciés.
Le contenu détenu par un compte de service sans personne nommée derrière.
Les abonnements et les tâches de rafraîchissement dont le propriétaire a changé de rôle depuis leur création.
Les équipes de migration arrivent à la même règle par l’autre bout. Réglez la propriété d’abord. Sinon, le problème voyage intact dans le nouvel environnement.
Quatre choses se font appeler gouvernance : la certification, la propriété, le contenu obsolète et le contrôle des changements. Ici, chacune est écrite comme une vérification que vous pouvez lancer, pas comme un objectif que vous pouvez énoncer. Il y est aussi question du seul changement qui passe une revue visuelle et reste faux.
Le contenu est la partie facile d’une migration. Voici ce qui doit bouger avec lui, ce qui a tendance à casser en silence ensuite, et ce qu’une migration gouvernée vérifie avant que quiconque approuve une exécution.
Deux identifiants Tableau qui font deux métiers différents. L’un porte les permissions d’une personne. L’autre étend une capacité de la plateforme. Choisir le bon garde aux commandes de qui voit quoi un modèle de permissions que vous avez mis des années à construire.