Liège, Wallonie, Belgique

Un cockpit ne regarde pas. Il aide à agir.

Un dashboard répond principalement à « que se passe-t-il ? ». Un cockpit métier doit aussi répondre à « qu’est-ce qui manque, qui doit décider, quelle action est possible et quelle preuve restera ? ».

Composants possibles

  • vues différentes selon rôle et périmètre
  • objets et états métier explicites
  • alertes liées à une action
  • documents et provenance
  • actions et validations
  • agents et automatisations encadrés
  • historique et preuves

Exemples

Quand un cockpit est réellement nécessaire

L’écran devient utile quand il supprime la reconstruction mentale du dossier.

Un cockpit prend son sens lorsqu’un utilisateur doit ouvrir plusieurs outils, reconstituer l’historique d’un objet, vérifier une échéance puis chercher qui doit agir avant de pouvoir prendre une décision. Le gain recherché n’est pas de concentrer toutes les données sur un écran : c’est de relier l’état courant, la provenance, les inconnues et la prochaine action dans une scène compréhensible par le rôle concerné. Une information qui n’influence aucune décision n’a pas à occuper l’espace principal.

Critères de réussite

  1. REPRISE

    Une autre personne peut comprendre où en est le dossier sans appeler celle qui l’a traité la veille.

  2. ACTION

    Chaque alerte importante mène à un objet, une raison et une action possible plutôt qu’à une notification isolée.

  3. RÔLE

    Direction, terrain, finance ou éducatif peuvent partager le même système sans subir la même densité d’information.

  4. TRACE

    La décision et son résultat restent rattachés à l’objet métier plutôt qu’enfouis dans une conversation séparée.

  5. MESURE

    On mesure le nombre de sources à consulter, les reprises manuelles, le délai de compréhension et les exceptions correctement remontées.