Un problème, pas une promesse générique.
Décision à préparer, usages exclus, personnes à impliquer, contraintes et prérequis informationnels et techniques.
Une entrée claire, un périmètre convenuNe partez pas de tout.
Ne partez pas de tout.
Partez d’une décision.
Le pilote sert à vérifier l’utilité de COGI sur un problème concret. Avant le lancement, on convient des objectifs, des personnes, des données, des délais, des restitutions et de l’investissement.
Qu’achète-t-on ?
Un parcours d’application délimité : méthode, outils configurés et accompagnement. Le périmètre est décrit dans la proposition.
Quand voit-on quelque chose ?
La première restitution a une échéance à convenir. Mesurer les effets sur le processus peut demander une vérification ultérieure.
Quel engagement, quel coût ?
Référents, disponibilités, prérequis et investissement se définissent en amont. Les éventuels coûts des modèles doivent être explicites.
Préparer le premier échangeDites-nous
Dites-nous
ce qui doit
devenir plus clair.
Pas besoin d’un cahier des charges. Il suffit du contexte, de la décision qui reste ouverte et de la contrainte qui la rend difficile.
Ce parcours prépare votre demande.
Rien n’est envoyé tant que vous ne l’avez pas confirmé. Vous pouvez l’envoyer d’ici, ou bien la copier ou l’ouvrir dans votre messagerie. N’indiquez pas de données de santé, de données personnelles de tiers ni d’informations confidentielles.
Ou écrivez à hello@cogi.co Rien n’est envoyé tant que vous ne l’avez pas confirmé. Vous pouvez l’envoyer d’ici, ou bien la copier ou l’ouvrir dans votre messagerie. N’indiquez pas de données de santé, de données personnelles de tiers ni d’informations confidentielles.
ÉTAPE 01 / 03 · LE CONTEXTE
De quelle organisation partez-vous ?
Ce qu’il faut convenir dans la propositionAvant le lancement,
Avant le lancement,
tout doit être lisible.
Ces points décrivent le périmètre à définir, pas une offre déjà chiffrée ni une disponibilité attestée.
Livrables et critères d’acceptation.
Dossier de la délibération, alternatives, données, désaccords et conditions de la vérification. On précise ce qui est inclus.
Un calendrier avec des conditions de lancement.
Durée, disponibilité des référents, responsabilités et échéance de la première restitution. On distingue le livrable des effets sur le processus.
Une hypothèse qui peut être démentie.
Indicateurs, situation de référence et conditions pour poursuivre, revoir ou arrêter le parcours. Aucune amélioration n’est tenue pour acquise.
Avant de nous rencontrerLes questions
Les questions
les plus fréquentes.
Faut-il d’emblée une intégration avec les systèmes de l’établissement ?
Ce n’est pas posé comme un prérequis universel. Le besoin d’intégrations, les données requises et la manière de les traiter se définissent selon le périmètre retenu et la configuration effectivement disponible.
Pouvons-nous commencer par un seul processus ?
C’est la manière proposée de construire la mise à l’épreuve : un problème circonscrit, des personnes concernées et des critères de vérification convenus. L’extension n’est pas automatique et demande une évaluation ultérieure.
Qui doit participer au premier échange ?
Un référent responsable du processus, quelqu’un qui en connaît le fonctionnement, et les référents techniques lorsque le périmètre touche des données ou des systèmes. La composition est adaptée au cas.
Que se passe-t-il si le pilote ne démontre pas d’utilité ?
Les conditions d’arrêt et de révision se conviennent en amont. Un résultat négatif ne doit pas être transformé en histoire à succès : c’est une information pour décider s’il faut poursuivre, et comment.