IBM a annoncé pour la première fois l'abandon de ces studios dans la version 10.2.2, publiée en 2014. À l'époque, de nombreuses inquiétudes existaient quant à l'endroit où cette fonctionnalité atterrirait et où iraient ces utilisateurs. Au fil du temps, nous avons vu IBM investir dans une très bonne UX, se concentrer également sur les nouveaux utilisateurs et le libre-service, et chercher à traiter les cas d'utilisation normalement avec Query Studio.
La bonne nouvelle est que les spécifications et définitions de Query Studio ont toujours été des mini-spécifications que le système Cognos a transformées en spécifications complètes utilisées pour Report Studio (maintenant appelée Authoring). Cela signifie que lors du passage à CA12, toutes les ressources Query Studio sont présentées dans Authoring.
Que faire face à ces utilisateurs mécontents ?
Maintenant que nous comprenons qu'aucun contenu n'est perdu en passant à Cognos Analytics 12 (CA), comprenons les impacts réels pour les utilisateurs. J'encourage toute personne se rendant à CA12 à comprendre l'utilisation des actifs Query Studio par son organisation. Les éléments à rechercher sont :
Le nombre d'actifs du studio de requêtes
Le nombre d'actifs de query studio consultés au cours des 12 à 18 derniers mois
Le nombre de nouveaux éléments Query Studio créés au cours des 12 à 18 derniers mois et par qui
Les types de conteneurs dans les spécifications (liste, tableau croisé, graphique…etc.)
Identifier les éléments Query Studio contenant des invites
Identifier les éléments Query Studio planifiés
Ces éléments de données peuvent vous aider à comprendre votre utilisation de Query Studio (QS) par vos utilisateurs finaux et vous permettre de vous concentrer uniquement sur le contenu actuellement utilisé, ainsi que d'identifier les groupes d'utilisateurs.
Notre premier type d'utilisateur est celui qui crée encore du nouveau contenu dans Query Studio. Pour ces utilisateurs, ils devraient s’intéresser aux merveilles du tableau de bord. Honnêtement, c'est une énorme mise à niveau pour eux, c'est très facile à utiliser, le contenu sera bien plus beau et même s'il a plus de puissance, il ne gêne pas… et il a des capacités d'IA sophistiquées. Sérieusement, créer du nouveau contenu dans Dashboarding avec un peu d'apprentissage est rapide et facile.
Notre deuxième type d'utilisateur est le groupe d'utilisateurs qui utilisent Cognos comme pompe de données avec des listes simples dans Query Studio et la fonctionnalité d'exportation. Ces usages doivent pouvoir atterrir dans un environnement Authoring simplifié (un skin pour Authoring pour réduire la fonctionnalité et la complexité) pour réaliser leurs exports. S’ils n’aiment pas voir l’interface, ils peuvent envisager de planifier ces éléments. Malheureusement, Dashboarding n'est pas une option pour ces utilisateurs s'ils cherchent à créer du nouveau contenu à exporter, car il existe plusieurs différences entre QS et Dashboarding. Actuellement, l'objet de liste dans Dashboarding a une limite de 1000 XNUMX lignes à afficher et à exporter. Cela est logique car il s'agit d'un outil visuel destiné à aider à trouver des réponses par rapport à un outil de pompe de données et d'exportation. Le deuxième problème est que la planification d'un tableau de bord (avec ou sans exportation) n'est pas prise en charge. Cela est également logique dans la mesure où la conception du tableau de bord est destinée à la représentation visuelle plutôt qu'à une présentation papier ou à la création de grandes images.
Alors, que se passe-t-il si les options de création (simplifiée) et de création de tableaux de bord sont rejetées ?
Si les utilisateurs de la pompe à données rejettent cette idée, il est temps de s’asseoir avec eux et de comprendre où ils prennent ces données et pourquoi. Des méthodes de livraison alternatives à partir de Cognos peuvent être utiles ou les utilisateurs peuvent simplement avoir besoin d'un accès à la création ou à la création de tableaux de bord. De plus, ils ont peut-être simplement transféré les données vers un autre outil au cours des dix dernières années et ne comprennent pas jusqu'où Cognos Analytics est réellement parvenu à répondre à leurs besoins.
Si les nouveaux créateurs de contenu rejettent cela, encore une fois, il va falloir comprendre pourquoi, quel est leur environnement préféré et leurs cas d'utilisation. Le tableau de bord devrait vraiment être présenté à ces utilisateurs, en se concentrant sur l'IA, son fonctionnement réel et sa simplicité.
La dernière option pour aider les utilisateurs à surmonter le rejet de Cognos Analytics 12 est une fonctionnalité peu connue appelée Cognos Analytics pour Microsoft Office. Cela fournit des plugins pour Microsoft Office (Word, PowerPoint et Excel) sur les installations Windows Desktop qui vous permettent soit d'extraire du contenu (visuels), soit d'interagir avec la pile de requêtes pour extraire des données directement dans Excel.
Pour conclure, oui, Query Studio a disparu, mais le contenu perdure. La majorité des cas d'utilisation peuvent désormais être mieux réalisés dans CA12, et l'idée de supprimer ou de geler Cognos Analytics sur une version 11 ne fera que gêner les équipes Analytics et BI. Ne sous-estimez pas le coût d'une migration vers une autre plateforme ou le coût des mises à niveau entre plusieurs versions majeures. Les utilisateurs devraient examiner les trois options CA12 :
- Tableau de bord avec l'IA.
- Une expérience de création simplifiée.
- Cognos Analytics pour Microsoft Office.
Enfin, les administrateurs doivent toujours comprendre ce que font les utilisateurs et comment ils utilisent le système plutôt que de simplement accepter les demandes. C’est le moment pour eux de devenir des champions de l’Analytics et de diriger les conversations et la voie à suivre.
