Cybergestion : quels sont les facteurs clés ?
Travail nomade, cyberadministration, out-sourcing, sous-traitance administrative : comment réussir ?

3/6   Synchroniser les flux
 
Lorsqu'un cyberacteur reçoit une demande de travail, il doit vérifier avant de déclencher son action si d'autres livrables vont lui parvenir de traitements parallèles amont.

Ce point est rendu crucial pour deux raisons :

Il se pose sur les processus complexes, où les risques de perte opérationnelle sont souvent importants

La généralisation du traitement de cas complets, au niveau du client et non du dossier, multiplie ce genre de situation


Cette synchronisation des flux est délicate, puisque l'existence de ces livrables optionnels dépend de décisions pas encore prises par l'une ou l'autre des équipes de cyberacteurs en amont.

Il est donc nécessaire de prévoir un blocage des capsules de travail tant que les travaux susceptibles de créer ces livrables optionnels ne sont pas clos. Un outil permettant au cyberacteur de situer les capsules de travail en cours liées au même cas est une aide utile.

Un cas particulier est le lancement d'activités de sous-traitance par un acteur. Le processus peut prévoir des cas où le sous-traitant ne renvoie pas le résultat à l'acteur émetteur. Il faut alors que l'émetteur soit informé qu'il n'a plus de retour à attendre.

Ainsi, la Cybergestion réussie synchronise les flux en gérant les dépendances amont-aval des traitements parallèles
.

 

 

Simplifier SCOR ( Supply Chain Operation Reference Model)

Une association américaine propose un modèle de référence pour la description des activités de la chaîne d'approvisionnement, dans une perspective de flux tirés.

http://www.supply-chain.org/public/scor.asp

Un document de 23 pages est proposé pour comprendre l'utilité du modèle SCOR et sa structure.

Le modèle comprend 4 niveaux de description, chacun étant censé correspondre à une strate décisionnelle différente de l'entreprise. Le niveau 1 aurait été ainsi utilisé dans le cadre de la fusion HP- COMPAQ.

Pour l'essentiel, SCOR aide les diverses sociétés de conseil intervenant dans un grand compte à coopérer aisément. Cependant IBM, IDS Scheer (…) ont déjà développé des variantes de SCOR qui ne sont plus nécessairement interopérables.

SCOR est trop complexe pour être utilisé en totalité dans un projet. L'expérience des anciennes méthodes OSSAD, Merise et SSADM ont montré qu'un modèle de trois niveaux était difficilement compréhensible dans le domaine informatique et inutilisable en organisation du travail.

Nous recommandons d'utiliser uniquement le niveau 3 du modèle . Il offre une bonne lisibilité de la chaîne de décision opérationnelle. Les outils et la méthode Mercutio de ProcessSoft permettent de réaliser aisément ce type de modélisation, en apportant les avantages suivants :

Approfondissement niveau 4 par changement de maille, sans drill-down, pour les zones méritant le détail

Réalisation très rapide et maintenance aisée

Simulation des charges de travail et des délais en temps réel.

SCOR offre surtout la possibilité aux chefs de projet de visualiser la pratique d'autres entreprises.
 
 

Représenter les flux

Un processus linéaire, qui enchaîne une étape après l'autre, sans arborescence, peut être décrit par une succession de paragraphes textuels, sans recours à un schéma.

« Un processus sans schéma est un pays sans routes ; une méthode non graphique est inutilisable »


A l'inverse, les processus réellement décisionnels enchaînent les décisions, souvent en parallèle. Voici le schéma simplifié des premières étapes d'ouverture de compte dans une banque.

Représentation avec parallélisme


Un texte ne peut clarifier seul de tels enchaînements.

La méthode graphique doit représenter la sous-traitance et la recherche d'expertise (cf le lien entre les étapes A et B ci-dessus). Une simple succession d'étapes a les défauts suivants :

Interrompt artificiellement les procédures

Ne rend pas compte du parallélisme

Ne rend pas compte des relances de boucles (ABCADABA) dans l'exemple ci-dessus

Ne permet pas de représenter des liens optionnels ou conditionnels

Accroît considérablement le nombre de pages de description

 

Représenter les événements et les fins

Un processus peut être déclenché par plusieurs événements ou répondre à plusieurs besoins. Il connaît généralement au moins deux fins (positive et négative) qu'il faut pouvoir représenter.

Faciliter la compréhension

Un schéma de flux ne doit pas afficher les combinaisons de tests oui/non, mais simplement le flux des livrables (cf. La_lettre des Processus N°5 ).

Un seul niveau de description est à utiliser, sans drill-down.

La structuration en colonne ou en ligne par acteurs est déconseillée, car elle crée une contrainte forte en augmentant le nombre de pages de description nécessaires.





Représentation sans parallélisme

 
   

www.processsoft.com

Suisse :+41 (0)21 351 30 31
France : +33 (0)1 55 27 39 54

 
    Pour vous abonner ou abonner une connaissance à cette lettre, cliquer s'abonner

Pour ne plus recevoir cette lettre, cliquer se désabonner

Pour retrouver toutes les précédentes "Lettres des processus" cliquer NewsLetter