Combien de cas faut-il observer?
Assez pour couvrir le chemin principal et les variantes significatives. Pour un flux de travail ciblé, cinq à dix cas soigneusement sélectionnés peuvent révéler plus qu'un grand échantillon de travail identique.
Applications Web et logiciels
Observer et documenter un processus d’affaires avant de créer un logiciel
Consignez les dossiers, les décisions, les solutions de rechange, les transferts et les exceptions d’un processus réel avant de le remplacer par un logiciel sur mesure.
Comment le flux de travail s’articule
- 1Sélectionner des cas représentatifs
- 2Observer le travail du déclencheur à l'achèvement
- 3Consigner les décisions et les éléments de preuve
- 4Comparer les variantes et les solutions de rechange
- 5Valider la carte avec les opérateurs
Les procédures documentées décrivent comment le travail devrait se produire. La découverte de logiciels nécessite également des preuves de la façon dont le travail se déroule sous la pression du temps, des informations incomplètes et des cas inhabituels. L'observation et l'échantillonnage des dossiers révèlent les règles que les entrevues seules ne révèlent pas toujours.
Choisir des cas qui exposent la variation
Suivez une affaire normale, une affaire urgente, une présentation incomplète, une réaffectation et une affaire qui exige un jugement de la direction. Supprimer les renseignements personnels ou sensibles des notes. L'objectif est de voir l'éventail des voies opérationnelles, et non de vérifier le rendement individuel.
Enregistrer séparément les éléments de preuve et les décisions
Pour chaque étape, notez le document modifié, l'information consultée, la décision prise, la personne responsable et le transfert suivante. Un tableur peut calculer une valeur, mais une personne peut encore inspecter une pièce jointe avant de l'accepter. Les deux actions font partie de la carte.
- Déclencheur et état d'achèvement
- Enregistrements créés ou mis à jour
- Contributions aux décisions et politiques
- Jugement ou dépassement manuel
- Démarrage et réponse attendue
Classer les solutions de rechange sans les rejeter
Une solution de rechange peut indiquer des efforts dupliqués, mais elle peut aussi préserver la flexibilité du système formel. Demandez pourquoi elle existe, à quelle fréquence elle se produit et ce qui échouerait si elle disparaissait. Remplacez-le seulement lorsque le flux de travail proposé répond aux besoins sous-jacents.
Par exemple, une feuille de suivi privée pour les travaux urgents, un courriel manuel utilisé pour confirmer des données ambiguës ou une convention de nommage qui aide le personnel à localiser les dossiers à travers les systèmes.
Convertir la carte en exigences vérifiables
Écrire les exigences relatives au comportement observable: qui crée un document, quelles données sont requises, quelles actions sont autorisées, ce qui se passe sur les informations manquantes et ce qui reste de l'historique. Examinez la carte et les exemples avec les opérateurs avant que la conception d'écran ou l'automatisation commence.
Observer un cas de l'arrivée à la fermeture
Choisissez une requête ordinaire et l'ombrer à travers l'opération. Enregistrez le déclencheur initial, les documents ou les messages reçus, chaque système ouvert, les décisions prises, les périodes d'attente, les retravaillés et les éléments de preuve utilisés pour déclarer l'achèvement. Demandez au personnel ce qu'il vérifie ce qui n'est pas écrit dans la procédure officielle; ces contrôles contiennent souvent les règles commerciales réelles.
Ensuite, examiner un cas incomplet, urgent, double et annulé. Comparez les itinéraires plutôt que de les calculer en un seul flux idéal. Un dossier de processus utile distingue le comportement observé, la politique déclarée, la solution de rechange locale et le changement proposé, de sorte que l'équipe du logiciel ne code pas accidentellement une habitude temporaire comme une exigence permanente.
| Observation | Preuves à saisir | Question à résoudre |
|---|---|---|
| La demande arrive | Chaîne, heure, champs, pièces jointes | Qu'est-ce qui crée le dossier faisant autorité? |
| Le personnel vérifie l'admissibilité | Sources ouvertes et décision enregistrée | Quelle règle est la politique contre le jugement? |
| Le travail attend | Raison, propriétaire, heure de début et de fin | Qui remarque un article en retard? |
| Clôture de l'affaire | Résultat, confirmation, documents conservés | Qu'est-ce qui prouve l'achèvement? |
Transformer les observations en une première version constructible
Traduire le processus en documents, rôles, états, transitions, champs requis, intégrations, notifications, rapports et exemples d'acceptation. Marquer l'incertitude au lieu de la remplir d'hypothèses. Si deux ministères utilisent des définitions différentes du terme complet, résolvez la règle opérationnelle ou conservez des états distincts jusqu'à ce qu'une décision politique soit prise.
Privilégier le plus petit chemin complet qui élimine les frictions significatives. Il peut commencer par la réception, l'affectation et la visibilité de l'état tout en laissant une exception financière inhabituelle dans le système actuel. Définir comment le travail franchit cette limite temporaire et comment l'équipe mesurera l'adoption, le temps de cycle, le retravail, les articles en retard et les corrections manuelles après la publication.
Repère visuel
De l’observation à la mise en œuvre
Chaque couche de planification convertit quelque chose que le personnel fait réellement en une exigence qui peut être revue et testée.
- 1
Cas observés
Travaux normaux, incomplets, urgents, en double et annulés.
- 2
dossiers d’affaires
Les entités et les preuves qui doivent rester cohérentes.
- 3
Règles et jugement
Décisions automatisables par rapport à l'autorité humaine.
- 4
États et cessions
responsabilité, attente, escalade et achèvement.
- 5
Limites du système
Outils existants, intégrations et étapes manuelles temporaires.
- 6
Cas d'acceptation
Des exemples qui prouvent que la première version supporte le flux de travail.
Questions pratiques
Questions fréquentes sur le sujet
Le nouveau logiciel devrait-il reproduire chaque étape existante?
Non. La carte explique le but et les contraintes. Les étapes qui ne compensent que les limites de l'outil peuvent être supprimées, tandis que les contrôles et les voies de jugement nécessaires doivent rester.
Poursuivre l’exploration
Projets et guides connexes
Collaborer avec Sun Cluster
Vous planifiez un système semblable pour votre organisation?
Sun Cluster cartographie les processus opérationnels et construit des logiciels commerciaux autour des dossiers, des décisions et des contrôles sur lesquels les équipes comptent.