Des flux d'approbation paresseux pour l'approbation

Un Slack Lazy Approval doit ressembler à la photo ci-dessus pour un e-mail "Lazy Approval". De nombreux utilisateurs souhaitent aujourd'hui exécuter des processus dans Slack plutôt que dans un e-mail et utilisent une approbation Slack Lazy comme cette approbation Lazy dans l'e-mail ci-dessus. De nombreuses suites BPM utilisent cette technique pour permettre aux réviseurs d'approuver ou de rejeter les demandes par e-mail. Un Slack Lazy Approval peut être utilisé de manière très similaire.

Le nom de ce reportage est génial. L'idée de base est de pouvoir approuver une demande en faisant le moins de travail possible. L'idée de "faire le moins de travail possible" est assimilée à l'idée d'"être paresseux". C'est tout à fait logique.

La paresse est-elle une bonne chose ?

L'idée de base est que l'utilisateur ne devrait pas avoir à se connecter au portail web du logiciel de gestion des flux de travail pour examiner et approuver une demande. Le problème est que se connecter à un site web, cliquer sur une boîte de réception, puis cliquer sur un dossier pour l'ouvrir, et ensuite approuver le dossier prend probablement entre 10 et 25 secondes selon la conception particulière du système de workflow.

10-25 secondes et 4 clics, c'est tout simplement trop long dans le monde hyper occupé d'aujourd'hui. Cela aurait semblé fou à dire il y a 20 ans, mais dans le monde d'aujourd'hui, c'est une réalité. Nous sommes habitués à la vitesse.

Une approbation paresseuse équivaut à un gain de temps

En d'autres termes, une autre façon de désigner une approbation paresseuse est de l'appeler "approbation permettant de gagner du temps". Il n'est donc pas surprenant que les gestionnaires soient ceux qui demandent le plus souvent la fonction d'approbation paresseuse. Les gestionnaires sont très occupés et leur temps est précieux. Il est donc logique qu'ils ne veuillent pas se connecter à un autre système. Ils veulent que les informations leur parviennent directement dans le système qu'ils utilisent le plus (e-mail), et ils veulent les approuver avec une réponse simple comme "Approuver ou rejeter".

Pourquoi les logiciels d'aujourd'hui nécessitent-ils tant de clics pour faire les choses ?

De nos jours, la plupart des logiciels d'entreprise se composent de trop de clics et font perdre trop de temps pour que les choses se fassent. Pourquoi en est-il ainsi ? Le fait est que la plupart des logiciels d'entreprise tentent d'en faire trop pour un trop grand nombre de rôles d'utilisateurs différents. Par conséquent, les interfaces ne sont pas bien conçues pour un utilisateur en particulier. Nous savons que c'est vrai parce que nous comparons intuitivement nos expériences d'utilisation de logiciels d'entreprise avec nos expériences d'utilisation de logiciels grand public. Si vous avez déjà comparé l'expérience des utilisateurs de SAP à celle de Lyft, vous saurez exactement ce que je veux dire. L'expérience de UX en matière de logiciels d'entreprise n'a pas suivi le rythme de celle des logiciels grand public.

Utiliser l'approbation paresseuse de Slack au lieu du courrier électronique

Selon Stewart Butterfield, le travail se fait aujourd'hui de manière détendue. Il va donc de soi que les managers veulent ajouter une approbation paresseuse à leur Slack Workflow. Mais en réalité, nous devrions aller plus loin. La semaine dernière, nous avons étudié la possibilité de mettre en œuvre un système de flux de travail complet en utilisant l'API d'entrée/sortie de ProcessMaker.

Allons un peu plus loin. Pourquoi ne pas être aussi paresseux que possible ? Pourquoi devrions-nous nous connecter à tout autre logiciel pour travailler ? Si Slack est notre interface de messagerie de choix, alors pourquoi voudrions-nous quitter cette interface ? Nous ne voudrions pas. Quitter l'interface signifie plus de clics et plus de temps perdu.

Nous devrions être en mesure de lancer des flux de travail, de les acheminer et d'approuver les demandes, tout cela à l'intérieur de Slack. Pour lancer un flux de travail, nous devrions pouvoir utiliser une simple commande slash comme celle-là :

"/purchase_request 20 computers" - Démarrer un workflow de demande d'achat pour acheter 20 ordinateurs

ou

"/leave_request 01/01/2018 01/10/2018 New Years Celebration" - Demande d'un congé pour prendre 9 jours de vacances.

C'est vraiment paresseux et cela permet une expérience utilisateur vraiment magnifique. C'est beau parce qu'il n'y a pas d'interface utilisateur. Nous devrions pouvoir utiliser une approbation paresseuse dans ce type de flux de travail.

Le monde sera de plus en plus paresseux.  

Qu'en est-il de l'approbation paresseuse ? Comment devrait fonctionner le Slack Lazy Approval ? Eh bien - il devrait être exactement comme le courrier électronique, mais en mieux. Le Slack est encore plus rapide que le courrier électronique et beaucoup plus rapide que l'utilisation d'une interface externe pour effectuer les approbations. La meilleure interface est celle que les utilisateurs utilisent déjà. Donc, si Slack est la meilleure interface pour la communication d'entreprise, alors nous devrions pouvoir tout faire directement dans Slack - créer des contacts dans SalesForce.com, créer un ticket dans Zendesk, envoyer un SMS, démarrer une réunion, etc. Toutes les applications cherchent à tirer parti de l'interface commune de Slack car, inévitablement, cette interface est la voie de moindre résistance pour faire du travail dans de nombreux types d'entreprises.

Le gotomeeting a pu se raser à environ 30 secondes de la façon dont les gens commencent un gotomeeting avec leur commande slash. Et ça fait du bien, n'est-ce pas ?

Utiliser une API de flux de travail pour les micro-services afin d'ajouter les approbations paresseuses à Slack

ProcessMaker I/O est une API de moteur de flux de travail allégé fournie sous forme de microservice en nuage. Il est idéalement adapté pour automatiser la tâche d'approbation paresseuse de Slack et le processus d'approbation paresseuse de Slack. Quel est son secret ? Il est simple et élégant. Un véritable "produit API-first" ne fait aucune hypothèse sur les interfaces. Comme ProcessMaker I/O n'a pas d'idées préconçues sur une interface, le développeur qui implémente l'API est libre de penser à ce à quoi l'interface doit ressembler. Le résultat est généralement de toute beauté.

Comme le dit le vieux dicton, "si vous avez un marteau, tout ressemble à un clou". C'est pourquoi API first est si puissant. Si vous n'avez pas d'interface, vous êtes libre de résoudre tous vos besoins en matière d'interface utilisateur de manière parfaite. Les systèmes BPM traditionnels de sociétés comme IBM, SAP, Oracle, Pega Systems, Nintex et d'autres voient tout comme un clou. Il en résulte que les utilisateurs sont soit coincés avec une mauvaise expérience utilisateur, soit que les développeurs sont coincés avec des mois de travail pour modifier les interfaces existantes afin de les adapter aux différents besoins.

Dans Slack, un flux d'entrées/sorties de ProcessMaker se produit à 100% dans Slack. Il fait TOUT dans Slack. Si la principale plate-forme de communication d'une entreprise est Slack, il n'est pas logique de forcer les utilisateurs à utiliser une autre interface pour effectuer des actions de workflow. J'en ai fait la démonstration dans mon dernier blog.

Libérez-vous - Commencez à vivre dans un premier monde API

J'espère que vous voyez où je veux en venir. API first est vraiment libérateur et très puissant. Dès lors que vous éliminez les intentions cachées d'essayer de convaincre les utilisateurs d'utiliser votre interface, vous êtes libre de faire EXACTEMENT ce que justifie un utilisateur ou un cas d'utilisation donné. C'est ainsi que les logiciels devraient être construits. L'âge d'or des API ne fait que commencer. Il en résultera une révolution dans les interfaces utilisateurs. Il suffit de regarder.

API First égale Better UX Design

Quel est donc le rapport avec l'approbation de Slack Lazy. C'est simple. Toutes les approbations devraient être aussi paresseuses que possible. C'est aussi simple que cela. Si vos approbations ne sont pas paresseuses, alors vous avez un problème de conception. Et si votre BPM a beaucoup de mal à s'adapter aux interfaces utilisateurs, vous allez vous retrouver avec des problèmes de conception. Il faut donc 4 clics et 25 secondes pour faire quelque chose qui pourrait être fait en 1 clic et demi-seconde.

Il suffit de regarder le message ci-dessous. Ne souhaitez-vous pas que chaque décision vous soit communiquée par un bouton "Approuver/Rejeter" directement dans le slack ? Lorsque vous verrez une implémentation comme celle-ci, vos utilisateurs diront : "hé, qui est le génie qui a finalement réussi à se débarrasser de l'interface ?

Cela nous semble si évident chez ProcessMaker maintenant que nous avons construit les E/S de ProcessMaker. Inscrivez-vous pour un compte de développeur gratuit dans ProcessMaker I/O et essayez notre exemple Slack dans l'API ProcessMaker I/O, et je pense que vous serez d'accord.