Power quoi ? (2/2)

Ma première Power App productive est née de la frustration.

Un peu de contexte : je suis l'administrateur de notre locataire global SAP Cloud for Customer. Disons que notre déploiement a été un peu… hasardeux. En partie à cause de notre partenaire, principalement pour des raisons internes (mais c'est un article pour une autre fois). En résumé, nous nous sommes retrouvés avec une poignée de bureaux utilisant le système sans véritable soutien, mais avec un lien commun – moi. C'est moi qui ai dirigé la préparation, la configuration et les ajustements sur site pendant nos blocs de déploiement progressif, donc je suis le nom et le visage auxquels tout le monde pense lorsqu'ils ont une question ou ont besoin d'aide.

Cela semble arriver beaucoup. Il est clair que je devrais travailler pour être moins utile.

Quoi qu'il en soit, ma boîte de réception est devenue essentiellement le bureau d'assistance du système. Ce qui n'est vraiment pas une expérience formidable pour quiconque est impliqué. Nous avons essayé plusieurs choses pour atténuer le problème : utiliser notre équipe de support informatique de première ligne pour le triage (ils l'ont simplement contourné) ; rédiger une documentation désolée pour nos chefs d'équipe locaux (ils ne l'ont pas lue); même en donnant à un collègue l'accès à ma boîte de réception, donc il y avait théoriquement moins de chance de manquer quelque chose (oui, avec le recul, c'était un peu idiot). Rien n'a vraiment résolu le problème. J'ai même demandé si je pouvais utiliser le système de billetterie qu'il utilisait, mais cela n'a pas vraiment abouti.

Attendez. Et si je construisais ma propre application de billetterie ?

C'est là que je devrais vraiment vous donner une belle description documentée de la construction, resplendissante de captures d'écran, de conseils et de leçons apprises. Cependant, vu comment j'ai commencé à écrire ceci certains…. il y a 5 mois? et que je n'ai toujours pas réussi à m'asseoir pour documenter rétroactivement quelque chose dont je ne suis pas particulièrement fier de toute façon (et qui existe peut-être encore ou non), je vais juste vous laisser avec un très bref aperçu ( VBO) (puis-je déposer ceci ?)

  1. J'ai commencé par bien fouiller dans le modèle d'application de billetterie de Microsoft. Cela utilisait Excel comme source de données - ce qui, croyez-moi, vous ne voulez jamais le faire, jamais, n'y pensez même pas, mais j'ai pris ces principes pour créer ma propre version.
  2. J'ai configuré mon application en utilisant SharePoint comme source de données. Cela signifiait que je pouvais utiliser nos groupes de sécurité organisationnels existants pour accorder l'accès, supprimant ainsi de nombreux maux de tête liés à la base de données. Cela signifiait également que je pouvais facilement vérifier et manipuler manuellement les données. Ce que, avouons-le, vous voudrez faire lorsque vous créerez votre première application.
  3. J'ai gardé la conception initiale simple, mais il y avait certains éléments clés que je savais que je voulais :
    • Vues utilisateur et administrateur séparées ;
    • Recherche dynamique rapide dans n'importe quelle liste de billets ;
    • Pouvoir voir les tickets terminés (plus pour me protéger si [quand] je fermais accidentellement quelque chose sur lequel je travaillais encore);
    • Le concept de vous ne pouvez pas faire confiance aux utilisateurs, ils doivent donc être contrôlés. Euh. …. Restreindre la saisie de l'utilisateur aux champs clés, afin d'améliorer la facilité d'utilisation. Cela sonne mieux, non ?
  4. Je suis rapidement passé à la conception itérative sans m'en rendre compte. À la manière de James… Tout d'abord, atteignez un jalon. Ensuite, testez la chose vous-même. Ensuite, notez ce qui vous énerve le plus. Allez le réparer. Rincer et répéter.
  5. Enfin, j'avais un prototype fonctionnel que je pouvais partager avec certains de nos utilisateurs. Cela nous a bien sûr fait passer à la conception itérative II : un peu comme mes tests personnels, sauf que vous échangez « ce qui vous énerve le plus » avec « ce que les utilisateurs font qui vous énerve le plus ».

Oui, j'adorerais dire que ma première application était "tout sur l'expérience utilisateur", mais franchement, il s'agissait davantage de réduire les questions insensées et les actions absurdes que je devrais corriger… Hé, c'est une stratégie qui fonctionne.

L'application a en fait complètement bombardé à la fin et nous sommes rapidement revenus dans Inbox Nightmare. Mais cela a moins à voir avec le concept et plus à voir avec mon manque de stratégie de mise en œuvre. Et c'est un article pour une autre fois...