On peut vous aider ?
Cherchez des réponses ou parcourez les rubriques de notre documentation
Workflows informels de collecte
Par nature, les processus de collecte via des classeurs Excel ne sont pas figés : les personnes qui saisissent, valident, transmettent, ainsi que les circuits de données entre ces personnes ne sont généralement pas définis formellement. Les personnes répondants ne sont pas forcément connus en central (et la maintenance d’un carnet d’adresse en central n’est pas forcément souhaitable), de plus, les flux ne sont même pas forcément homogènes entre les entités interrogées.
Lors de la migration vers la suite Gathering Tools, certains des aspects informels de la collecte Excel peuvent être préservés. Quelques-uns de ces aspects sont décrits dans cet article.
Diffusion et collecte : généralités
Délégation de la saisie
Lorsqu’une réponse est saisie dans un questionnaire GT, celui-ci peut être enregistré pour compléter la réponse plus tard, transmettre le fichier qstx (par mail ou par tout autre moyen de transfert de fichier- partage de fichiers, etc…) à une autre personne qui pourra également compléter la réponse ou même transmettre la réponse.
En utilisant la validation de l’adresse mail par GTAnswer , il est possible d’obtenir l’adresse mail des personnes ayant effectivement transmis la réponse plutôt que l’adresse mail des seuls correspondants, destinataires initiaux des questionnaires.
Axes de diffusion
Les axes de diffusion des questionnaires ont essentiellement trois fonctions
- Découpe des données lors de l’envoi
- Confort de visualisation par gestionnaire, avec les axes de validation supplémentaires.
- Confort intégration (dernière réponse par entité), avec les axes de validation supplémentaires.
Axes de diffusion et axes de validation supplémentaires
L’envoi des questionnaires est réalisé via des axes de diffusion qui permettent de déterminer les entités. Ce mode de distribution peut ne pas être suffisant pour décrire la population des répondants :
Les personnes saisissant effectivement les réponses ne sont pas les personnes à qui le questionnaire initial est envoyé. Les entités émettant une réponse peuvent ne pas être connues à l’avance en central.
Dans le cas où une personne est le seul contact pour la collecte de nombreuses entités, l’envoi d’un nombre réduit de questionnaires peut être opportun.
Axes de validation supplémentaires : Détermination des entités de réponse par le répondant
L’utilisation d’axes de validation supplémentaire permet d’obtenir des réponses (et un suivi de ces réponses) à un niveau plus fin que les entités adressées directement par mail avec GTServer.
En utilisant un ou plusieurs axes de validation supplémentaire (correspondant à un ou des composants dans le questionnaire), les réponses dans GTClient seront automatiquement séparées suivant les valeurs de retour de ce champ : les entités de réponse sont déterminées par le répondant. Les réponses correctrices (nouvelle réponse pour une entité d’un axe de validation supplémentaire) seront gérées automatiquement lors de la visualisation des réponses et lors de l’intégration.
Attention : les axes de validation supplémentaire peuvent être saisis directement ou être le résultat de formules mais doivent dans tous les cas renvoyer des données de type chaîne (il faut utiliser le flag TFMT à la création du composant saisissable ou s’assurer que la formule renvoie bien une chaîne).
La découpe des données par l’axe de validation supplémentaire ne devrait induire d’intersection des périmètres de saisie (cf Réponses partielles). Par exemple, si l’un répondait pour les services Production et RH dans le même questionnaire et l’autre pour les services Commerce et RH.
La découpe des données par l’axe de validation supplémentaire reste globale au questionnaire (pas de niveaux différents suivant les motifs, les transpositions ou les multi-onglets)
Dans GTAnswer, la visualisation des campagnes avec des axes de validation supplémentaires introduit une subtilité : le graphique de suivi ne comporte plus l’indicateur du nombre d’entités en attente. En effet, les entités étant créées dynamiquement, il n’est pas possible de déterminer à l’avance le nombre total d’entités. Ceci implique également que les réponses ne se trouveront jamais dans le fil de discussion du questionnaire initial : en effet, les axes de validation ne peuvent recevoir de valeur vide. Un nouveau fil de discussion sera donc créé pour chaque nouvelle entité, et le message de lancement y sera recopié.
Axes de visualisation
Les axes de visualisation sont choisis dans la racine du questionnaire à la conception de l’action de lancement et permettent lors du suivi des réponses de voir les valeurs des axes/champs de visualisation saisis ou calculés dans le questionnaire sans que cela modifie la définition des entités (définies par les axes de diffusion et de validation supplémentaires).
Les utilisations les plus fréquentes correspondent à :
- une pré visualisation de certains résultats du questionnaire sans avoir à l’ouvrir
- une visualisation d’un statut de l’entité dans le cadre d’un workflow informel (la bascule dans un statut différent est effectuée par les formules ou la saisie dans le questionnaire)
Exemples
Exemple 1 : les entités ne sont pas connues en central
Un questionnaire est envoyé à des agences et s’adressent aux services de ces agences. Les services ne sont pas connus précisément, pas plus que les personnes devant renseigner les réponses pour ces services.
Un questionnaire peut être envoyé à un correspondant pour chaque agence, il pourra alors lister les services de l’agence (dans un motif par exemple) et transférer le questionnaire à une personne dans chacun des services. Ces personnes pourront alors choisir le service qui les concerne et transmettre la réponse à GTServer via GTAnswer.
Il est possible de restreindre les choix de service pour un répondant donné.
Dans GTAnswer, les réponses sont différenciées par agence et par service.
Exemple 2 : questionnaire de données personnelles
La fonction gtvalidmailaddress() peut être utilisée pour identifier les adresses mails des répondants (ou les comptes utilisateurs). Cette fonction peut être placée dans un contrôle GT (via la fonction de déclaration gtcontrole dans Excel lors de l’import dans Design).
Elle peut également être spécifié comme valeur de l’un des axes de validation supplémentaire ou d’un axe de visualisation.
Les réponses dans le fil de discussion seront alors automatiquement visualisées (et/ou validées) par adresses mails collectées. Un répondant pourra toujours fournir des réponses correctrices.
Exemple 3 : réduction du nombre de questionnaires envoyés
On souhaite récupérer des informations par filiales et unités (toutes deux pouvant être connues au moment du lancement de la campagne). On adresse les questionnaires à une seule personne par filiale, cette personne se chargeant ensuite de transférer les questionnaires à chaque unité.
Certaines filiales comportent cependant plus de 20 unités. De manière à ne pas engorger la boîte mail du correspondant initial pour la filiale, il peut alors être opportun d’envoyer un questionnaire pour la filiale concernée avec un axe de validation supplémentaire qui soit l’unité.
Le correspondant initial n’aura plus qu’à transférer le seul mail reçu à chacune des personnes en charge de la réponse pour chaque unité.
Comparativement à l’envoi d’autant de questionnaires qu’existent de filiales et d’unités, ce mode de distribution et collecte est un peu plus complexe à mettre en œuvre si le questionnaire est prérempli (les données embarquées dans le questionnaire concernent toute la filiale, tandis que les données à présenter pour chaque unité devront généralement se restreindre à l’unité).
Exemple 4 : questionnaire d’alertes
On cherche à collecter les différentes alertes, remarques et suggestions émises par les collaborateurs de l’entreprise. On crée une seule entité (la société) et un seul questionnaire est envoyé. Le questionnaire peut être déposé dans un partage de fichiers (partage réseau, web, etc…). Un axe de validation supplémentaire est créé en utilisant un composant de texte libre dans le questionnaire désignant le sujet de la remarque.
Une personne souhaitant émettre une alerte ouvre le questionnaire inscrit un sujet et transmet la réponse. Cette personne peut émettre une réponse correctrice pour le même sujet en inscrivant le même libellé dans le composant du sujet.
Si la validation d’adresse mail est demandée, l’émetteur de la remarque peut être identifié, sinon les réponses seront anonymes.
Si l’on ne souhaite pas que les alertes soient différenciées par un sujet, on peut également utiliser la date de transmission de la réponse comme axe de validation supplémentaire : cette date sera sous la forme d’un contrôle dans le questionnaire contenant la formule =Maintenant() à convertir en texte puisque c’est un axe de validation supplémentaire, donc plutôt sous une forme similaire à =Annee(Maintenant())& »-« &Mois(Maintenant())& »-« &Jour(Maintenant()).
Un deuxième axe de validation supplémentaire portant sur un composant contenant la fonction gtvalidmailadress() pourra également être spécifié pour différencier les réponses par individu émetteur.
Un axe de visualisation (GT>=3.7) pourra indiquer un statut ou un état de validation de la réponse.
Exemple 5 : visualisation des réponses au fil de l’eau : réponses intermédiaires
On souhaite visualiser en central l’avancement de la réponse au fil de l’eau (sans que les réponses soient considérées comme définitives).
Un composant spécifiant si la réponse est une réponse intermédiaire ou non (de type case à cocher) permet d’envoyer la réponse en central sans que toutes les contraintes soient vérifiées sur le questionnaire. Ce composant est utilisé comme axe de validation supplémentaire (par l’intermédiaire d’une formule calculant une chaîne à partir de la case à cocher).
Tant que le correspondant ne considère pas la réponse comme complète, la case est cochée, la réponse peut être transmise et les informations peuvent être visualisées/suivies dans GTAnswer.
Une fois la réponse finalisée, la case est décochée et la réponse doit vérifier toutes les contraintes pour être transmises. Les deux ensembles de réponses intermédiaires et finales sont clairement différenciés dans GTAnswer.
Ce fonctionnement peut être étendu à plusieurs niveaux de réponses intermédiaires, permettant un suivi des différentes réponses.
Réponses partielles et circuits de réponses
Réponses partielles
Par réponses partielles, on entend les cas où la réponse transmise par l’utilisateur ne renseigne que certains champs/lignes (motifs) de la réponse finale, sans qu’une réponse finale globale avec tous les champs/lignes renseignés ne soit effectivement transmise avec GTAnswer.
Les réponses partielles sont possibles, il suffit lors de l’intégration d’utiliser toutes les réponses (premier panneau de l’action d’intégration), puis de faire une sélection suivant des critères plus fins si nécessaire.
Autoriser les réponses partielles est généralement contre-indiqué, car cela implique, entre autres, de :
- ne pas avoir de vision globale de la réponse pour une entité en central (sauf après l’intégration). Ce qui implique une difficulté de gestion des réponses correctrices
- ne pas pouvoir effectuer tous les contrôles de cohérence au niveau de la réponse
Réponses correctrices et réponses partielles
Les réponses correctrices pourront être mises en œuvre si une subdivision explicite ou implicite des données du questionnaire est réalisée.
Par exemple, un questionnaire listant tous les produits vendus en un mois par une entité sans distinguer ces différentes ventes ne permettra pas de corriger les informations fournies lors de transmissions précédentes pour la même campagne.
En revanche, si un numéro de commande est spécifié, celui-ci pourra servir de clé de mise à jour (les suppressions pourront se faire par une case à cocher par commande spécifiant que celle-ci doit être supprimée). La visualisation de la réponse globale en central restera problématique tant que les réponses ne sont pas intégrées (pour faire intervenir les règles de préséance par date et par numéro de commande).
Dans tous les cas, des contraintes globales ne pourront être appliquées dans le questionnaire au moment de la saisie.
Réponse « partielle » en utilisant un axe de validation supplémentaire
Lorsqu’une certaine discipline (ou des contraintes définies dans le questionnaire) isolent les périmètres de saisie de chacun des sous-répondants pour une entité, un axe de validation supplémentaire peut être construit en identifiant le périmètre de saisie (cela pourra être un ensemble d’unités par concaténant de la combinaison des unités par exemple). Les réponses ne sont pas vraiment partielles : ce sont les périmètres de saisie spécifiés pour l’entité adressée qui définissent des « sous-entités ».
Circuits de réponses
Les réponses partielles étant difficiles à gérer, elles sont généralement déconseillées.
En utilisant le seul questionnaire et sans autoriser les réponses partielles, on ne peut pas avoir de circuit de saisie/réponse en étoile où chaque répondant adresse le questionnaire rempli pour la partie qui le concerne à la personne en charge de la transmission de la réponse. La consolidation avec GTAnswer de données issues de plusieurs documents n’est en effet pas possible.
Si les données d’un questionnaire doivent être saisies par plusieurs personnes, différentes possibilités existent :
- Matrice de saisie Excel dans le cadre d’un schéma de réponse en étoile ou en cycle
- Discipline dans le cadre d’un cycle de réponse
- Adaptation du questionnaire à l’utilisateur dans le cadre d’un cycle de réponse
Matrices de saisie Excel dans un schéma de réponse en étoile
Chaque répondant utilise une matrice Excel de saisie (classeur Excel préparé pour en importer les données dans le qst) pour saisir les données et envoie cette matrice à la personne chargée de répondre avecGT Answer.
Lorsque les données saisies par chaque personne se limitent à un ensemble de compartiments (motifs, multi-onglets et transpositions) pour lesquels il est le seul à fournir cette information, la consolidation des matrices de saisie Excel se fera simplement en important successivement ces différentes matrices dans le questionnaire.
On peut se servir en effet de plusieurs matrices de saisie Excel pour importer les données dans GTAnswer directement à condition que les noms de zones pour l’import déclarés dans chaque matrice de saisie n’existent que dans cette matrice de saisie. Les noms de zones Excel peuvent aussi être calculées en fonction des données saisies et renvoyer une valeur d’erreur (#ref! par exemple) pour signaler à GTAnswer que cette zone n’est pas à importer. Cf Import multi matrices de saisie.zip.
Les matrices de saisie Excel ne pourront être utilisées pour importer des données à l’intérieur de multi-onglets du questionnaire.
Plusieurs matrices de saisie Excel ne peuvent approvisionner le même motif du questionnaire. Lors de l’import dans un motif, toutes les données existant dans le motif sont d’abord effacées avant d’importer les nouvelles venant d’Excel.
Cependant, plusieurs motifs de structure identique peuvent être créés pour importer chacun les données d’une matrice de saisie (cf Import multi matrices de saisie.zip).
La personne répondant au questionnaire peut également consolider les matrices de saisie Excel en rassemblant les données dans Excel, éventuellement manuellement. Cette solution n’est généralement pas préconisée à cause de son peu de fiabilité et/ou de son coût de maintenance : les consolidations doivent être effectuées manuellement, les automatisations avec des macros-commandes Excel posent des soucis de maintenance.
Circuit cyclique de réponse discipliné
Le correspondant principal reçoit le questionnaire, il peut alors le transmettre au premier saisisseur qui le complète et le transmet au second, ainsi de suite jusqu’à revenir au correspondant principal.
Tous les correspondants peuvent cependant modifier l’ensemble des informations dans le questionnaire et transmettre la réponse en central à tout moment. L’utilisation de verrous et de contraintes dans le questionnaire (cf paragraphe suivant) est une alternative intéressante.
Adaptation du questionnaire à l’utilisateur dans le cadre d’échanges informels
Dans les cadres d’échanges du ou des questionnaire(s) au sein de l’entité interrogée, il est possible en utilisant la validation d’adresse mail, de modifier le fonctionnement du questionnaire en fonction de l’utilisateur par application de verrous, de contraintes etc.. pour autoriser ou non l’accès à certaines données, autoriser ou non la transmission de la réponse par l’utilisateur, etc.
Les cadres d’application sont variés : validation locale avec des axes supplémentaires ou non, circuit de réponse discipliné, etc…
Que peut-on contrôler dans le questionnaire en fonction de l’adresse mail validée ?
- Qui saisit quels composants du questionnaire ?
- Qui valide ?
- Qui transmet la réponse ?
- Quelles sont les délégations de saisie, de transmission ?
- Quelle est la mécanique de modification du statut de la réponse ?
La mise en oeuvre repose sur l’utilisation de listes d’adresses mail désignant les personnes habilitées à réaliser telle ou telle opération dans le questionnaire. Si l’adresse mail renvoyée par gtvalidmailadress() ne fait pas partie de la liste des adresses mail habilitées à faire tel ou telle opération, des composants pourront être verrouillés ou des contraintes calame pourront être activées.
Ces listes d’habilitation pourront être approvisionnées en central (lors du lancement du questionnaire), voire complétées par le correspondant principal de l’entité à la réception du questionnaire (lors de l’intégration, ces listes complétées pourront être réutilisées pour la campagne suivante, ce qui permet de déléguer la gestion des droits au correspondant principal).
Les verrous (gtverrou) permettront d’empêcher certaines personnes de modifier les valeurs de certains composants.
Les contraintes calame (gtcontrainte) pourront empêcher certains utilisateurs de renseigner des ensembles incohérents ou de transmettre la réponse (si l’utilisateur ne peut transmettre la réponse.
Des formules pourront modifier un statut de réponse, visualisable directement avec les axes de visualisation.
En utilisant la surcharge des destinataires pour la relance et les mots-clés entre double crochets dans les messages, le gestionnaire peut envoyer le questionnaire avec la dernière réponse à toutes les personnes devant modifier les données pour le statut suivant.
Que ne peut-on pas contrôler dynamiquement dans le questionnaire ?
- L’ajout et la suppression de lignes dans un motif (une transposition peut être utilisée pour simuler le motif).
- L’ouverture du questionnaire
- La visualisation des valeurs de composants spécifiques (même si l’utilisation d’une mise en forme de type blanc sur blanc est possible, la sélection de la cellule dans le document permettra de visualiser la donnée).
- Le fait de forcer les gens à répondre ou à transmettre le questionnaire à la bonne personne au bon moment. Aucun outil informatique ne saurait encore contraindre une personne à effectuer une action (et c’est probablement une bonne chose…).
Exemple 1 : Questionnaires avec validation locale
Le correspondant initial pour l’entité reçoit le questionnaire.
Si celui-ci est la personne devant valider, il transmet le questionnaire à la personne devant saisir. Celle-ci peut renseigner les données dans le questionnaire mais ne peut transmettre la réponse : une contrainte calame empêche la transmission de la réponse si l’adresse mail de l’utilisateur ne fait pas partie de la liste des adresses mail habilitées à transmettre la réponse (cette liste est définie en central et renseignée lors du lancement de la campagne). Le saisisseur doit transmettre le questionnaire au valideur (correspondant initial) qui lui peut transmettre la réponse.
Le fonctionnement peut être étendu à plusieurs niveaux de validation à condition de limiter le choix du niveau de validation (niveau 1, niveau 2, etc…) aux seules personnes concernées, que les utilisateurs se transmettent le questionnaire contenant la dernière réponse et se coordonnent (de la même manière qu’ils le feraient avec un classeur Excel subissant différents niveaux de validation).
Si le correspondant initial est le saisisseur, il renseigne le questionnaire, il ne peut envoyer la réponse en central et transmet donc le questionnaire par mail à la personne devant valider (et pouvant envoyer la réponse en central).
Il est également possible d’utiliser les brouillons pour ce type de flux.
Exemple 2 : Délégation sur axes de validation supplémentaires
Le questionnaire est envoyé au correspondant principal de l’entité, chaque entité comprend une liste de sous-entités, la sous-entité pour la réponse est choisie via une liste déroulante. La liste des sous-entités pour chaque entité peut être définie en central ou par le correspondant principal.
Le correspondant principal définit quelles seront les personnes habilitées à renseigner les données pour chaque entité en listant les adresses mail en regard de chacune des sous-entités. Il peut ensuite transmettre le questionnaire aux personnes chargées de saisie pour les sous-entités.
La transmission de la réponse peut passer obligatoirement par le correspondant initial ce qui permet d’avoir une première validation avant réception en central par GTServer.
Le suivi des réponses pour les sous-entités apporte un confort non négligeable dans le cas de sous-entités nombreuses.
Exemple 3 : Délégation d’un questionnaire découpé en blocs de saisie
Un questionnaire peut être découpé en zones dont les données sont modifiables par certains correspondants seulement (exemple partie RH, partie finance, etc…).
Pour chacune des zones, une liste d’habilitation est créée rassemblant les adresses mails pouvant modifier les composants de cette zone. Des verrous sont créés sur chacune des zones vérifiant que l’adresse mail de l’utilisateur appartient à la liste d’habilitation pour cette zone.
Le correspondant principal transmet le questionnaire au premier répondant qui complète sa partie, puis transmet le questionnaire au correspondant suivant, etc… jusqu’au correspondant initial pour transmission en central.