Applications Web et logiciels
Transformez un processus manuel en une carte prête pour la mise en œuvre avant de choisir les écrans et les fonctions de l’application Web.
Comment le flux de travail s’articule
Les équipes décrivent souvent une application Web proposée comme une ensemble d’écrans: tableau de bord, formulaire, rapport et zone d'administration. Commencer par cartographier le processus permet de mieux définir la portée. Un processus simple de traitement des demandes montre comment les personnes, les enregistrements, les statuts, les règles et les interfaces se connectent avant le début de la conception de l'écran.
Choisissez le dossier central de l'entreprise: demande, demande, cas, commande, emploi ou approbation. Énumérez les renseignements qu'il gagne au fil du temps et les éléments de preuve nécessaires pour les faire avancer. Un enregistrement partagé empêche chaque écran d'inventer une version différente de la même œuvre.
Pour une demande de service, le dossier peut commencer par les détails du demandeur et une description, puis obtenir un propriétaire assigné, une évaluation, des travaux prévus, des notes d'achèvement et un historique d'approbation.
Remplacer les statuts vagues par des transitions explicites. Au lieu de dire qu'une demande devient approuvée, notez qui peut l'approuver, ce qui doit déjà être présent, quelle heure est saisie et ce qui se passe ensuite. Cela transforme les étiquettes en règles qui peuvent être mises en œuvre et testées.
un transfert survient lorsqu'une autre personne ou un autre système doit agir. Enregistrez le destinataire, l'information transmise, la réponse attendue et le chemin d'escalade. De longues périodes d'attente indiquent souvent les rappels, files d'attente ou intégrations les plus utiles dans la première version.
Ne pas automatiser un transfert qui n'a pas encore de responsabilité claire. Le logiciel peut envoyer une notification, mais il ne peut décider quelle équipe est responsable sauf si la règle commerciale existe.
Une fois que les actions sont claires, les regrouper en interfaces: un formulaire de réception, une file d'attente de travail assignée, une vue de détail, une vue d'approbation et une petite zone de configuration. Chaque écran a maintenant un utilisateur, un but et un ensemble d'actions autorisées. Les fonctionnalités qui ne supportent pas le flux de travail mappé peuvent sortir de la première version.
Considérez une équipe des opérations qui reçoit les demandes par courriel, copie les détails dans un tableur, demande à un gestionnaire d'approuver, planifie le travail et envoie les mises à jour de l'état manuellement. L'enregistrement passant par le processus est la demande de service — pas le courriel, la ligne de tableur, ou l'événement de calendrier éventuel. Donnez-lui un identificateur et énumérez les informations nécessaires à chaque décision.
La première carte pourrait utiliser les renseignements reçus, être prête à être examinée, approuvée, prévue, en cours, achevée et annulée. Chaque transition désigne l'acteur, les champs requis, les preuves créées, la notification et le chemin d'exception. Ce n'est qu'à ce moment-là que l'équipe doit établir un formulaire de réception, examiner la file d'attente, demander des détails, afficher l'horaire et consulter la page sur l'état du client.
Repère visuel
Les écrans suivent le travail: d'abord définir l'enregistrement et les transitions, puis identifier l'interface dont chaque acteur a besoin.
Demande de service
Nommez le dossier et les renseignements qui doivent demeurer ensemble.
États
Décrivez les étapes significatives, y compris l'attente et le travail annulé.
Transitions
Nommez l'acteur, l'action, les règles et les preuves pour chaque changement.
transferts
Afficher la responsabilité, les cibles de réponse et le routage des exceptions.
Écrans
Formulaires dérivés, files d'attente, détails et vues d'état à partir des actions requises.
Exécutez des exemples réels à travers la carte avant de le traiter comme une spécification. Inclure une demande avec des renseignements manquants, une présentation en double, une approbation refusée, un membre du personnel non disponible, une annulation du client après la planification et une tâche effectuée en dehors du système. Demandez où le dossier attend, qui remarque, et comment le chemin normal reprend.
La carte est prête à être mise en oeuvre lorsqu'une autre personne peut déterminer l'état prévu et l'action suivante sans interpréter une politique non écrite. Il n'a pas besoin de tous les rapports ou préférences futurs. Il a besoin du premier flux de travail complet, des limites de permission, des systèmes source, des responsabilités de notification, du comportement de défaillance et des scénarios d'acceptation.
| Scénario | État prévu | Propriétaire | Preuves |
|---|---|---|---|
| Données manquantes | Besoins d'information | Équipe d'accueil ou demandeur | Raison du champ manquant |
| Approbation rejetée | Révision requise ou terminée | Demandeur | Décision et observations |
| Assigné non disponible | Réaffectation en attente | Directeur des opérations | Historique des missions |
| Le client annule | Annulé | Équipe de services | Source et heure d'annulation |
Questions pratiques
Assez détaillé pour identifier les dossiers, les utilisateurs, les états, les règles importantes, les intégrations et les exceptions. Les spécifications par champ peuvent suivre une fois le modèle d'exploitation convenu.
Documenter les variantes et la raison de chacune. Certains reflètent des exceptions valides; d'autres sont des solutions de rechange. Le futur flux de travail devrait rendre ce choix explicite plutôt que de le cacher.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster conçoit des applications Web personnalisées autour des utilisateurs réels, des dossiers d'affaires, des flux de travail et des limites du système.
