Modèle d'arbre de décision en matière d'escalade des risques
Un arbre décisionnel d'escalade des risques couvrant la tolérance, le seuil d'impact, l'autorité et l'urgence, avec des résultats nommés par la gestion locale à signaler en tant qu'incident.
Qu'est-ce que le processus modèle d'arbre de décision en matière d'escalade des risques ?
L’escalade va mal dans deux directions. Les risques qui auraient dû augmenter restent dans un registre pendant un mois parce que personne ne se sentait en droit de les augmenter, et les risques qui auraient pu être gérés par le propriétaire arrivent lors d'une réunion du conseil d'administration parce que les augmenter semblait plus sûr que de décider. Les deux échecs viennent de la même lacune : les critères existent dans la tête des gens plutôt que sur une page. Un arbre décisionnel d'escalade des risques comble cette lacune en rendant chaque test explicite et responsable à partir de preuves, de sorte que le même risque suit le même chemin, quel que soit celui qui le détient.
Cette page est un arbre de décision, pas une cartographie des processus. Il répond quelle option est correcte et qui détient la bonne décision, de sorte que les questions se déroulent au milieu et les branches se terminent à des endroits différents. Une carte de processus répond à ce qui se passe ensuite et à qui le fait, de sorte que ses étapes s'étendent de gauche à droite et convergent vers une seule réalisation. Si vous souhaitez connaître le flux de bout en bout qui suit une escalade une fois qu'elle a été déclenchée, utilisez l'organigramme du processus de gestion des incidents sur /fr/templates/organigramme-du-processus-de-gestion-des-incidents, qui couvre la journalisation, la priorisation, la déclaration d'incident majeur, la violation du SLA et la clôture. Ce graphique s'arrête à la décision de routage ; celui-là reprend après.
Le modèle utilise des couloirs clairs qui nomment qui répond à chaque question plutôt que de cartographier les départements : propriétaire du risque, chef de projet, conseil d'administration du projet et comité exécutif des risques, à travers cinq étapes, de la capture à l'escalade. Huit décisions restent sur la colonne vertébrale, et des critères sont écrits dans des commentaires sur les quatre qui comportent de véritables seuils : l'écran de sécurité, légal ou réglementaire, le test de tolérance, le test de budget et d'autorité et le seuil d'impact. Cinq points de terminaison nommés remplacent le seul chemin heureux qu'une cartographie de processus utiliserait.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre voies de droits de décision plutôt qu'une carte de département (propriétaire du risque, chef de projet, comité de projet, comité exécutif des risques) réparties en cinq étapes : capture, dépistage, test de tolérance, seuil et calendrier, itinéraire d'escalade.
- Deux questions de sélection qui contournent complètement la notation : « Le risque s'est-il déjà matérialisé ? et « Exposition en matière de sécurité, juridique ou réglementaire ? ». Un Oui sur l'un ou l'autre peut atteindre « Un préjudice ou une violation est-il imminent ? », dont le Oui lance « Déclencher la procédure d'incident » et se termine par « Escalader maintenant en tant qu'incident ».
- L'agence locale : « Dans les limites de la tolérance au risque du propriétaire ? mène à « L'atténuation active en vaut-elle la peine ? », où Non se termine par « Accepter et enregistrer le risque » et Oui par « Atténuation dans les limites du budget et des pouvoirs ? » : À l'intérieur se termine par « Gérer localement avec surveillance », Au-delà renvoie le risque même si l'exposition était tolérable.
- La division de routage sur « Impact au-dessus du seuil d'escalade ? » : ci-dessus passe directement à "Informer le président du comité des risques", et ci-dessous passe au test de timing plutôt que d'escalader uniquement sur la valeur.
- Le test de timing qui sépare les deux voies d'escalade : « Décision nécessaire avant le prochain conseil d'administration ? envoie Oui hors cycle au président du comité, et Non via « Préparer le résumé de l'escalade » vers « Transmettre au comité de projet ».
- Cinq points de terminaison distincts au lieu d'un seul entonnoir : gérer localement avec surveillance, accepter et enregistrer, transmettre au comité de projet, transmettre au comité exécutif des risques et transmettre maintenant en tant qu'incident.
Quand utiliser ce modèle
- Rédaction de la section d'escalade d'un plan de gestion des risques, où les critères doivent être énoncés plutôt qu'implicites.
- Intégration de nouveaux gestionnaires de projets ou de risques afin que l'escalade soit motivée par des tests écrits plutôt que par le tempérament individuel.
- Régler un différend sur les droits de décision : les couloirs indiquent qui répond à chaque question, ce qui constitue généralement le véritable différend.
- Fournir l’assurance ou des preuves d’audit que des critères de remontée d’informations existent, sont convenus et ont été appliqués à un risque spécifique.
- Réaliser un examen post-incident lorsqu'un risque a été signalé trop tard, pour déterminer quels tests auraient dû se déclencher et ne l'ont pas été.
Comment cela fonctionne
Renommez les voies selon vos véritables droits de décision
Remplacez le propriétaire des risques, le chef de projet, le comité de projet et le comité exécutif des risques par les organes qui détiennent réellement l'autorité dans votre organisation. Gardez les voies réservées à celui qui répond à chaque question. S'il n'existe pas de comité des risques, fusionnez cette voie avec le conseil d'administration et dites-le, plutôt que de laisser un organe dans l'organigramme qui ne se réunit jamais.
Écrivez le seuil d'escalade sous forme de chiffre et de durée
« Impact au-dessus du seuil d'escalade ? » est inerte jusqu'à ce que vous attachiez des chiffres. La plupart des organisations fixent un chiffre de coût lié à la limite de dépenses déléguée et un chiffre de calendrier lié au flottant ou à un jalon contractuel, puis traitent celui qui est dépassé en premier comme déclencheur. Mettez les deux sur le nœud pour que tout le monde puisse appliquer le test sans rien demander.
Définir la tolérance séparément pour chaque propriétaire
« Dans les limites de la tolérance au risque du propriétaire ? suppose que la tolérance a été déléguée et enregistrée. Définissez-le par propriétaire ou par catégorie de risque, pas une seule fois pour l'ensemble du projet, et indiquez-le dans les mêmes unités dans lesquelles vous évaluez les risques. Si rien n'est écrit pour un propriétaire, la réponse honnête est Non, et le risque augmente.
Diviser le budget de l'autorité
« Atténuation dans le cadre du budget et de l'autorité ? » est délibérément deux tests. Une solution peut être abordable et nécessiter néanmoins une décision que le propriétaire n'est pas autorisé à prendre, comme modifier un contrat, mettre fin à un fournisseur ou accepter un retard. Nommez les deux limites pour que la branche Au-delà se déclenche pour la bonne raison.
Définir le déclencheur de l'incident et qui peut l'appuyer
Décidez de ce qui fait que « Un préjudice ou une violation est-il imminent ? » a Oui, et nommez qui pourra le déclarer sans attendre personne. C'est la seule branche qui ignore la gouvernance, ses critères doivent donc être suffisamment objectifs pour s'appliquer en dehors des heures d'ouverture, et elle doit s'appliquer directement à votre procédure d'incident existante plutôt que d'en décrire une nouvelle.
Acceptez l'itinéraire hors cycle, puis parcourez-le et publiez une version
« Une décision est-elle nécessaire avant le prochain conseil ? » ne fonctionne que s'il existe un véritable parcours hors-cycle : une chaise nommée, un temps de réponse et un moyen d'enregistrer la décision. Testez l'arbre terminé par rapport à trois ou quatre risques de votre registre, corrigez les branches qui les envoient dans un endroit manifestement erroné, puis publiez-le sous forme de version signée afin que les gens sachent quelle révision s'applique.
Questions fréquentes
Quelle est la différence entre un arbre décisionnel d’escalade des risques et un processus d’escalade des risques ?
Un arbre de décision répond à une question de routage : face à ce risque, laquelle des options disponibles est correcte et qui a le droit de la choisir. Sa forme est une chaîne de tests se terminant par plusieurs résultats différents. Un processus d'escalade répond à ce qui se passe une fois l'itinéraire choisi : qui est informé, quel paquet est préparé, ce que fait l'organisme récepteur, comment la décision revient et comment elle est enregistrée. Sa forme est une chaîne d’étapes convergeant une fois terminées. Vous avez besoin des deux, et ils sont plus faciles à gérer sous forme de diagrammes séparés. Utilisez cette arborescence pour décider de l'itinéraire et de l'organigramme du processus de gestion des incidents pour le flux de bout en bout qui suit.
Quand un risque doit-il être signalé à un niveau supérieur plutôt que géré localement ?
Cette arborescence s'intensifie sur quatre déclencheurs indépendants, dont chacun est suffisant. L'exposition se situe en dehors de la tolérance enregistrée par le propriétaire. L'atténuation coûte plus cher que le budget délégué ou nécessite une décision dépassant l'autorité du propriétaire. L'impact dépasse le seuil financier ou échéancier convenu. Ou bien le risque comporte une dimension sécuritaire, juridique ou réglementaire, auquel cas il quitte la route locale quelle que soit sa valeur, car la tolérance pour cette classe d'exposition est effectivement nulle. Tout le reste peut être géré localement avec surveillance, ou accepté et enregistré si aucune atténuation n’en vaut la peine.
Quelle est la différence entre l’appétit pour le risque et la tolérance au risque ?
L'appétit est le montant et le type de risque que l'organisation est prête à prendre en premier lieu ; la tolérance est la limite dans laquelle un propriétaire spécifique peut travailler avant que quelqu'un d'autre doive être impliqué. L'arbre teste la tolérance, car c'est la question opérationnelle à laquelle un propriétaire de risque peut réellement répondre un mardi après-midi. ISO 31000 ne prescrit aucun seuil pour aucun des deux (elle attend de l'organisation qu'elle définisse ses propres critères de risque et qu'elle les maintienne cohérents avec ses objectifs), de sorte que les chiffres sur ces nœuds doivent provenir de votre plan de gestion des risques plutôt que d'une norme.
Que se passe-t-il si le risque s'est déjà produit ?
Cela cesse d’être un risque. Un risque est un événement futur possible avec un propriétaire et une atténuation ; une fois matérialisé, il s'agit d'un problème et, si un préjudice ou une violation est imminente, d'un incident. C'est pourquoi « Le risque est-il déjà matérialisé ? » est la première question de l'arborescence : un Oui quitte entièrement la route des risques, déclenche la procédure d'incident et se termine par « Escalader maintenant comme incident » sans attendre un exercice de notation ou la prochaine réunion du conseil d'administration. PRINCE2 trace la même ligne, traitant un risque survenu comme un problème plutôt que de continuer à le gérer dans le registre des risques.
Chaque escalade doit-elle attendre une réunion du conseil d’administration prévue ?
Non, et l’arbre en fait un test explicite plutôt qu’une improvisation. « Une décision est-elle nécessaire avant le prochain conseil ? » prend un risque inférieur au seuil d’impact mais dont le temps est critique et l’achemine hors cycle vers le président du comité des risques, au lieu de le conserver jusqu’à ce que le cycle rattrape son retard. L’avantage d’écrire le test est qu’il légitime également l’autre réponse : si la décision peut réellement attendre, le résumé de l’escalade est préparé et le risque est transmis au prochain conseil prévu, et personne n’a à se demander si cela était raisonnable.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus passe le relais à Organigramme du processus de gestion des incidents.
Suit
- Organigramme du processus de gestion des incidents — Un organigramme de processus de gestion des incidents interfonctionnels couvrant la journalisation, la priorisation, l'escalade des incidents majeurs, la violation des SLA, la résolution et la clôture.