Le module processus

Cette leçon présente le module processus, qui permet de rendre explicite l'organisation.

Présentation de la notion de découpage en processus

Le découpage en processus est utile aussi bien pour organiser sa documentation personnelle que pour organiser celle d'une entreprise, association ou administration.

Idéalement, l'ensemble des activités devrait décrire exhaustivement tout ce qui est fait au niveau de l'organisation. Une activité est un processus élémentaire qui est fait généralement par une seule personne, en une seule fois, c'est à dire que l'on ne peut pas redécouper. Ensuite, on regroupe les activités en processus simples, puis ceux-ci en processus plus généraux, et ainsi de suite.

Dans la pratique on ne part généralement pas des activités quand on envisage la description du fonctionnement d'une organisation. En effet, ce qui vient immédiatement à l'esprit correspond souvent à des processus intermédiaires. Par exemple 'Les devis'. Si on y pense, c'est parce-que par exemple le temps d'établissement d'un devis est jugé trop long, ou que que le taux d'acceptation des devis est trop faible. A partir de là, il faut créer une fiche processus 'Devis', et ensuite expliciter ce processus, c'est à dire le détailler en les multiples sous processus qui le composent. Par exemple 'Prendre rendez vous avec le client pour lui faire préciser son besoin', 'choisir une solution technique', 'consulter les fournisseurs en vue du chiffrage', 'établir le devis', 'le présenter au client', 'relancer le client', etc. Or, ce qui pose problème, par exemple en constituant un goulot d'étranglement, ce n'est pas le processus devis dans son ensemble, mais un des sous processus, sur lequel on va être amené à approfondir l'analyse. De plus, ce qui conduit généralement à l'inefficacité, l'insatisfaction, c'est la présence de boucles inutiles liées au fait que l'on démarre une activité en ayant pas à disposition tous les éléments techniques et ressources nécessaires à sa bonne exécution. Par exemple, au moment du choix technique, on constate que une question n'a pas été posée au client.
Dès que l'on va entrer dans l'analyse, lister les sous processus ne suffit généralement pas, et l'on sera amené à établir un schéma de type UML décrivant le processus et explicitant les dépendances entre les différents sous processus. Nous verrons au niveau 3 de l'autoformation comment documenter cela dans Storga.

Dans un deuxième temps qu'il convient de se poser régulièrement la question : est-ce que ce que je suis en train de faire à l'instant fait bien partie de m'on arborescence de processus, où a été oublié.

Remarquez aussi que dans certains cas, il peut y avoir une correspondance forte entre un processus et une organisation, si bien que l'on risque de ne pas bien savoir dans laquelle des deux pages ranger une information. Par exemple 'Payer ses impôts' est un processus, et 'Les Impôts' (ou 'Le fisc') est un tiers. Dans ce cas, il est judicieux de déplacer l'une des deux fiches (en utilisant le mode organiser de Storga) pour la mettre soit dans la même page Storga que l'autre, soit dans une sous page ce cette autre. Dans notre exemple, on pourrait décider de ranger dans la même page la fiche processus 'Payer ses impôts' et la fiche organisation 'Impôts'. A l'inverse, si l'on paye des impôts dans plusieurs pays, on peut préférer créer une sous page avec le tiers 'Fisc France' à l'intérieur de la page 'Payer ses impôts'.

Voici, pour conclure cette introduction, quelques références externes concernant la notion de processus :

↣ Article wikipedia présentant la gestion de processus

L'association APQC propose, sous la dénomination PCF (Processus Classifaction Framework), une classification standardisée des processus. Nous ne recommandons pas sa mise en oeuvre en l'état, mais la lecture de leur arborescence de processus peut être utile pour ne pas oublier certaines activités, et suggérer des regroupements pertinents mais différents du découpage induit par l'organigramme de votre organisation.

Le module découpage en processus

Voici le module processus complet, prêt à l'emploi :

Le formulaire de recherche et le formulaire de création

La mécanique de ces deux formulaires est très similaire à celle présente dans les modules personnes et organisations.

Relisez et vérifiez que vous comprenez bien le programme du formulaire de création, qui n'est qu'une révision de ceux présents dans les modules personnes et organisations :

if button_name="create"
  if process=""
    error "Vous devez indiquer un nom de processus !"
  if process<>"" and (lookup_form_id @processes_list process process)<>""
    error "Cette fiche sujet existe déjà"
  new_form @process_model page @processes_folders subpage (process 0 1) (process 0 1) subpage process process url_call copy_fields
    void
  process := ""

La fiche modèle des processus

La fiche modèle d'un processus est assez simple. Pour établir l'arbre des processus, on s'est contenté d'un champ 'Processus parent' au niveau de chaque fiche processus. Il s'agit là d'une propriété de topologie élémentaire : pour décrire sans ambiguïté un arbre, il suffit que chaque noeud (hormis la racine) indique quel est son unique parent.

Les sous processus de chaque processus sont donc tous les processus ayant ce processus particulier indiqué au niveau de leur champ 'Processus parent'. Ils sont listés automatiquement au niveau de la fiche via un bloc Storga de type 'vue'. Cette vue fait référence à l'état listant l'ensemble des processus, et utilise le nom du processus pour positionner le champ  'parent_filter' de l'état.

La liste de tous les processus

Attention: ne confondez pas la sous page contenant la liste de tous les processus, simple état équivalent de ce qui se trouve dans les modules personnes et organisations, avec celle mise en forme, que nous présenterons plus loin.

La seule bizarrerie de cet état de la liste des processus est sa formule de filtrage :

(process contains process_filter) and (shunt parent_filter="root" parent="" (parent contains parent_filter))

là où l'on aurait pu attendre une version plus simple du type :

(process contains process_filter) and (parent contains parent_filter)

Le '(shunt parent_filter="root" parent="" ' qui a été ajouté permet, en indiquant 'root' au niveau du filtre, de ne lister que les processus principaux, c'est à dire ceux qui ne font pas partie d'un processus plus grand, c'est à dire ceux dont le champ 'parent' est vide.

La version mise en forme de la liste des processus

Voici, en mode organiser détaillé, et en affichant les blocs cachés, le contenu de la sous page présentant la liste des processus mise en forme.

On y trouve deux parties.

La partie 'Les processus généraux' est constituée d'un formulaire et d'une vue.
Pour rappel, une vue est l'affichage d'un autre état en récupérant, dans un formulaire de la page en cours, les valeurs de certains champs paramètres de l'affichage de l'état.
Ici, on a construit un formulaire 'Paramètres de cette liste de processus' spécifiquement pour fournir les valeurs de 'process_filter' et 'parent_filter' au niveau de l'affichage de l'état de la liste des processus. Comme on a positionné 'parent_filter' à 'root', la liste des processus n'affichera que les processus principaux, c'est à dire ceux dont le champ 'parent' est vide. De plus, en positionnant son attribut meta, on a caché ce formulaire qui ne sert qu'à la mécanique interne de Storga.

La partie 'Tous les processus' est constituée d'un bloc de type 'Dataware', et d'un programme.
Un bloc de type dataware sert à remplir par calcul un tableau en dimension 2, et à l'afficher, soit sous forme de tableau, soit sous forme de graph. Le dataware peut aussi accessoirement servir à effectuer des dessins libres.
Ici, le dataware est affiché sous forme de tableau, et contient simplement la liste de tous les processus, mise dans un ordre qui la rende explicite. En effet, les processus principaux sont triés par ordre alphabétique, et ensuite les processus secondaires sont présentés sous forme indentée, sous leur processus parent.

L'utilisation du bloc dataware fait l'objet de toute la partie 'Mise en forme avancée' du manuel Storga, et dépasse très largement le niveau de compétence attendu au niveau 2 de l'autoformation. Pour autant, voici quelques explications concernant le programme qui rempli le tableau du bloc dataware :

var (Index Str Str) path
dataware pl
  dw_bin_column "Processus"
  dw_category "abstract" label "Résumé"
  report @processes_list
    field Str process parent abstract
    dw_bin process link "/page/"+form_id color hsl 0 0 100
    dw_value process "abstract" abstract
    path process := shunt parent="" process "?"
  var Bool again := true
  while again
    again := false
    report @processes_list
      field Str process parent
      if path:process="?" and parent<>"" and path:parent<>"?"
        path process := path:parent+"/"+process
        dw_bin process label (repeat (path:process count "/") "·   ")+process order path:process
        again := true

Le coeur de ce programme est la variable 'path' qui vise à associer à chacun des processus une chaîne de caractères que l'on appellera dans la suite son chemin, et qui est la liste de tous les processus conduisant à celui-ci, en descendant la séquence de parentée.
Par exemple, si le processus 'Relance' à pour parent le processus 'Facturation' qui a pour parent le processus 'Administration', alors au niveau de la variable 'path', on veut associer à l'entrée 'Relance' le chemin 'Administration/Facturation/Relance'.
En effet, une fois que l'on a associé son chemin à chaque processus, il suffit alors d'afficher la liste des processus en respectant l'ordre lexicographique des chemins. De plus, pour savoir le nombre de points à mettre avant le nom du processus pour créer l'indentation, il suffit de compter le nombre de signes '/' au niveau de son chemin.

Le problème, c'est que l'on ne peut pas déterminer le chemin d'un processus directement, par une simple formule. On ne peut le déterminer que par itération.
On effectue donc un premier parcours de la liste des processus, dont la trame est la suivante :

report @processes_list
  ...
  path process := shunt parent="" process "?"

ce qui signifie que si le processus n'a pas de parent, alors son chemin est simplement son nom, et sinon son chemin est provisoirement la chaîne de caractères '?' qui signifie que le chemin n'est pas encore déterminé.

Ensuite, on effectue un certain nombre de nouveaux parcours de la liste des processus. On effectue un nouveau parcours aussi longtemps que la variable 'again' est vraie, ce qui signifie que l'on a réussi à déterminer le chemin d'au moins un nouveau processus lors du parcours précédent.
Le coeur de la boucle correspondant à chaque parcours est :

    report @processes_list
      ...
      if path:process="?" and parent<>"" and path:parent<>"?"
        path process := path:parent+"/"+process
        ... 

ce qui signifie que si chemin correspondant à ce processus n'est pas encore déterminé, mais qu'il a un parent, et que le chemin du parent est déterminé, alors on peut déterminer le chemin de ce processus par concaténation du chemin de son parent, du caractère '/', et de son nom.

Remarquez enfin que toutes les instructions de ce programme commençant par 'dw_' servent à remplir au vol le bloc dataware qui effectuera l'affichage effectif. Elles sont documentées dans cette page du manuel Storga :

→ Le type de données Dataware

Dans le cas présent, on va utiliser une 'bin' (ou corbeille, ou ligne, comme vous préférez) pour chaque processus. La ligne qui est importante est :

dw_bin process label (repeat (path:process count "/") "·   ")+process order path:process

qui enregistre de nouveau un processus (avec le type dataware, on peut déclarer plusieurs fois la même ligne; c'est la dernière définition qui sera prise) et précise :
via l'option 'label' le nom du processus indenté.
via l'option 'order' l'ordre d'affichage des différents processus.

Travaux pratiques