Questions Réponses Cartographie de Processus

Chapitre 5 CHAPITRE 5
QUELQUES RÉPONSES CONCRÈTES

À DES QUESTIONS SPÉCIFIQUES
ET DES SITUATIONS PARTICULIÈRES
L’application de la méthodologie de cartographie par l’aval rencontre par-

fois des situations particulières qui demandent une réflexion et la mise en
œuvre de solutions spécifiques. Dans les pages qui suivent, nous propo-
sons un certains nombre de ces solutions.
© Éditions d’Organisation
288 LA CARTOGRAPHIE DES PROCESSUS
QUESTIONS RELATIVES À L’IDENTIFICATION

DES DONNÉES DE SORTIE
Y a-t-il une méthode pour identifier les données de sortie

d’un processus?
Hélas non. Nous avons l’habitude de considérer notre travail en terme
d’activités et non pas en terme de résultats à atteindre. Lorsque nous occu-
pons un emploi nouveau, il nous est expliqué le plus souvent par une
description des tâches à effectuer : «Tu fais ceci et après tu fais cela, etc.»
Caractériser les activités d’un ensemble de ressources par les résultats
obtenus est un exercice inhabituel et nous devons faire un petit effort pour
cela. Nous devons donc réfléchir à notre processus comme s’il était une
micro entreprise et nous demander ce que cette micro entreprise fabrique.
Nous tentons dans ce cas d’établir un catalogue, non pas de nos activités,
mais des services que nous proposons à nos clients, lesquels seront nos
processus utilisateurs en interne ou les clients en externe. Lorsque les
données de sortie sont matérielles ou informatives, cela ne pose pas trop de
problème. En revanche, les données de sortie immatérielles sont parfois
difficiles à déterminer. Un cas d’école intéressant nous est fourni par les
activités des processus de maintenance par exemple. Une donnée de sortie
n’est pas «intervention sur machine en panne». Ceci est une activité et pas
un résultat. Mais nous pouvons nous poser la question de savoir quel est le
résultat d’une intervention de maintenance. Il se matérialisera sous la
forme d’une machine remise en état de marche. Nous écrirons donc
«machine remise en état» ou bien encore «machine dépannée».
L’utilisateur d’une donnée de sortie

doit-il obligatoirement travailler avec et la transformer
à son tour en donnée de sortie ?
Non, la notion d’utilisateur est très large. Un utilisateur est un processus
qui utilise une donnée de sortie pour travailler avec ou plus simplement il
est un processus concerné par la donnée de sortie. A ce titre, il est utile de
le faire figurer dans la liste des utilisateurs pour lui demander ses attentes.
Le but étant d’améliorer le fonctionnement global de l’organisation, l’avis
d’un processus concerné par une donnée de sortie peut être utile pour
progresser.
Par exemple dans une fromagerie, un processus «d’affinage» est chargé du
fonctionnement d’une centrale de régulation de la température et de
l’hygrométrie tout bonnement parce que cette centrale est située dans son
CHAPITRE 5 • QUELQUES RÉPONSES CONCRÈTES À DES QUESTIONS SPÉCIFIQUES 289
territoire. Ce processus est donc responsable des données de sortie de

l’activité de ce matériel qui sont la température et l’hygrométrie dans tous
les services concernés par ces paramètres (les ateliers de production et les
stockages principalement). Ces services sont utilisateurs et doivent, à ce
titre, être consultés pour connaître leurs attentes et améliorer le service le
cas échéant. Autre exemple, toujours dans la même fromagerie. Le service
qualité est utilisateur de l’étiquette qui est disposée sur les fromages parce
qu’il est concerné par le contenu qui doit répondre à la réglementation et à
d’autres critères de type qualitatifs. Pour cette raison, le service qualité doit
être consulté pour connaître ses éventuelles attentes.
Le rangement ou les résultats d’une activité de rangement

peut-il être considéré comme une donnée
de sortie ?
Cela dépend du processus concerné par cette activité. Par exemple, un
stock d’outillages rangés sous la responsabilité d’un atelier de production
n’est pas une donnée de sortie pour cet atelier car c’est une règle interne.
Par contre, un stock d’outillages rangés sous la responsabilité d’un
processus de maintenance pour utilisation par un atelier de production
devient une donnée de sortie de ce processus de maintenance.
Les quantités de produits à fabriquer ou les délais de

production ou de livraison sont-ils des données de sortie ?
Non. Ce sont des paramètres qui caractérisent des données de sortie. Une
quantité en elle-même ne signifie rien si elle ne concerne pas un objet par
exemple. Idem pour un délai. Ces informations jouent donc en consé-
quence un rôle d’indicateur de performance ou d’activité pour des données
de sortie considérées comme production principale d’un processus.
Un transport de pièces est-il une donnée de sortie ?

Non, c’est une activité mais dont le résultat peut s’exprimer sous forme
d’une donnée de sortie. Celle-ci peut être désignée par exemple par
« pièces mises à disposition » ou bien encore « pièces acheminées dans la
zone X ».
Faut-il faire figurer dans les contrats d'interfaces les

données de sortie de type administratif que l’on trouve
dans tous les services ?
Par exemple, les feuilles de relevés d’heures qui sont transmises chaque
soir au service du personnel, par exemple les demandes de congés ou ce
genre de formulaires qui apparemment ne posent pas beaucoup de

problèmes et dont la présence sur les contrats d'interfaces peut en compli-
quer la présentation.
Il faut les évoquer ne serait-ce qu’une fois car contrairement aux idées
reçues, ces documents sont souvent à la source de nombreux problèmes
chez les utilisateurs. Ces formulaires ne présentant pas de priorité absolue,
ils sont souvent traités quand on a le temps (c'est-à-dire pas souvent) et
génèrent de nombreux dysfonctionnements.
Un indicateur est-il une donnée de sortie d’un processus ?

Oui et non.
Oui, si et parce qu’il est le résultat d’une activité du processus en question
et qu’il sera utilisé par la direction dans un tableau de bord par exemple.
Dans ce cas, comme pour toute donnée de sortie, il convient d’interroger
les clients utilisateurs pour savoir si la forme, la fréquence et autres carac-
téristiques de cette donnée de sortie leur convient ou s’il faut y changer
quelque chose.
Non, s’il est seulement utilisé par le pilote du processus pour évaluer l’effi-
cacité des ses activités ou de ses performances.
La question n’est pas essentielle en ce sens que l’indicateur étant identifié
et montré dans un contrat d’interfaces, il est inutile qu’il figure à la fois
dans la liste des données de sortie et dans la notice «indicateurs» en bas de
page de contrats d'interfaces.
Par contre, un indicateur d’activité d’un processus, qui est calculé par un
autre processus, sera une donnée de sortie du processus à l’origine du
calcul. Par exemple, un COQ (Coût d’Obtention de la Qualité), calculé par
le service qualité comme indicateur de performance de la production, sera
une donnée de sortie du service qualité et la production en sera un des utili-
sateurs.
Comment formuler certaines données de sortie résultant

d’activités de surveillance ou de veille ?
Rappelons-le, une donnée de sortie est obligatoirement la matérialisation,
le résultat de l’activité des ressources d’un processus. Comment peut-on
exprimer le résultat d’une activité de veille? Tout simplement par un état
souhaité. Par exemple : « processus en état de fonctionnement » ou
« législation du produit respectée » ou bien encore « produit contrôlé
conforme». Le cas est plus facile à résoudre lorsque qu’un enregistrement
existe et constate l’état. Dans cette situation, la donnée de sortie est le

document d’enregistrement.
Une demande peut-elle constituer une donnée de sortie ?

Oui car c’est bien le résultat d’une activité dans un processus. Cette affir-
mation pourrait se discuter dans la mesure où une donnée de sortie doit être
porteuse de valeur ajoutée. Effectivement, la vraie donnée de sortie est
celle qui matérialise le fruit d’une réelle activité à valeur ajoutée. Mais
nous ne souhaitons pas que le respect absolu des principes soit nuisible à
la finalité de notre démarche, autrement dit nous nous accordons le droit
de déroger à un principe si cela va dans le sens que nous recherchons c'est-
à-dire l’amélioration entre les processus et les fonctions. D’une manière
générale, une donnée de sortie est surtout un lien entre deux processus. Le
travail sur les interrelations entre les processus (l’amélioration de la
communication) ne peut se faire que si les liens entre les processus sont
identifiés. C’est pour cette raison que nous nous efforçons d’inventorier
toutes les données de sortie. Parce qu’une donnée de sortie, quand elle
arrive dans un autre processus, devient obligatoirement une donnée
d’entrée et à ce titre elle peut entraîner un dysfonctionnement si elle ne
convient pas à l’utilisateur. Ainsi, une demande mal formulée obligera
l’utilisateur à revenir vers le fournisseur pour lui demander un complément
d’informations (temps perdu) ou plus dommageable, cette demande mal
formulée entraînera une mauvaise réponse et donc du temps perdu et des
ressources mal utilisées.
Les demandes d’achats par exemple doivent être identifiées comme
données de sortie dans tous les processus qui expriment des besoins en
fournitures ou en services.
Une procédure peut-elle être une donnée de sortie ?

Une procédure peut s’appliquer soit à un processus particulier pour réguler
ou maîtriser une activité interne, soit à un ensemble de processus. Par
exemple, une procédure qui définit les modalités de tenue de revues de
conception dans un bureau d’études appartient à la première catégorie et
une procédure qui définit les règles d’achats dans un organisme qui ne
dispose pas d’un service centralisé d’achats appartient à la seconde.
Dans le premier cas, la procédure est interne à un processus. Elle est
validée par le pilote du processus. Elle est applicable aux ressources
humaines et matérielles du processus. En conséquence, elle ne constitue
pas une donnée de sortie.
Dans le second cas, la procédure est applicable dans plusieurs processus

concernés par la règle. Elle doit être élaborée et validée par un processus
identifié. Pour ce genre de règle, le processus en question ne peut être
qu’un processus de management. La procédure d’achat constituera une
donnée de sortie d’un des processus de management existant. Il est
possible, comme nous l’avons déjà évoqué précédemment, de constituer
une boîte spécifique que nous intitulerons par exemple «processus opéra-
tionnels de management » dans laquelle nous mettrons les achats,
l’hygiène, etc. Ce processus à mettre dans la famille des processus de
management sera bien entendu piloté par le dirigeant de l’organisme.
Sous quelle forme se manifestent les données de sortie

d’une activité de formation ?
Les données de sortie des activités de formation sont quasiment impossi-
bles à définir si nous n’avons pas pris auparavant la précaution de préciser
les objectifs pédagogiques que nous souhaitions atteindre. L’activité de
formation est un transfert de savoir, de savoir-faire et de savoir être qui
s’applique à de trop nombreuses situations pour pouvoir répondre à des
définitions standardisées. Il convient donc par conséquent de définir les
résultats de l’activité, par exemple en terme de capacité des personnes
formées à faire, à répondre, à se comporter de telle ou telle façon.
Les données de sortie pourront s’exprimer peut-être ainsi :
– Etudiant capable de réaliser une expertise comptable.
– Technicien capable de décider de la faisabilité d’une commande.
– Commercial capable de négocier un contrat.
– Stagiaire capable d’élaborer un tableau Excel d’analyse et de suivi de
projet de construction, etc.
Faut-il être précis dans la formulation des données

de sortie ?
Oui car ce travail d’identification des données de sortie est nouveau. Il est
d’usage dans les organismes de travailler les uns avec les autres sans se
poser de question sur ce qui sort d’un processus et sur ce qui entre dans un
autre. Lorsque nous identifions les données de sortie, il est nécessaire d’en
définir le nom (l’intitulé) avec précision. Il convient que ce nom désigne
sans ambiguïté un résultat précis ou une décision claire pour tout le monde.
En l’absence de ces précautions, les personnels et les pilotes ne parlent pas
le même langage et ne savent plus ce que signifie les données de sortie
identifiées sur les contrats.
Par exemple, des commerciaux avaient désigné sous trois vocables diffé-
rents la même donnée de sortie. L’un d’eux la nommait « délais », un autre
« infos sur délais» et un troisième « priorités clients ». Il s’agissait en fait
du délai de livraison négocié avec le client et qui était transmis au service
planning.
Comment identifier les données de sortie d’une activité

collective comme par exemple une réunion ou une
décision collective de faisabilité ?
Il faut attribuer la donnée de sortie résultant de cette activité collective à un
seul processus, choisi parmi ceux qui participent à l’activité. Ce processus
aura le souci de déclencher l’activité, d’établir les comptes rendus le cas
échéant. Les données de sortie correspondantes figureront sur son contrat
d'interfaces. Il est possible de formaliser ces dispositions dans une procé-
dure qui sera issue d’un processus de management.
Ce genre de question se pose également pour des réalisations collectives
de type « étude AMDEC » ou « plans d’expérience ». Comme évoqué
précédemment, il suffit d’attribuer l’organisation des études et le résultat à
un processus de l’organisation.
Une donnée de sortie peut être une présence à un événement. Par exemple,
une représentation dans des instances officielles. Une chambre de
commerce et d’industrie se doit de représenter sa compagnie dans de
nombreuses séances de délibération. Le processus chargé de cette repré-
sentation la fera figurer dans sa liste de données de sortie.
Des données de sortie temporaires doivent-elles figurer

sur les contrats d'interfaces ?
Oui, mais il est aussi possible de ne pas les formaliser. Cela dépend du
degré de maturité du système de management de la qualité et du niveau
d’intégration de la relation client/fournisseur en interne. Si les relations
entre les processus sont excellentes et si la mission temporaire est de
faibles dimensions, il ne sera pas utile de la formaliser comme donnée de
sortie. Il en est de même pour les demandes qui peuvent être faites aux
autres processus pour accomplir cette mission. Elles seront formalisées ou
non selon l’importance de la mission et la qualité des interrelations entre
processus. Par exemple, un processus de collecte de lait a été chargé de
faire un film sur cette activité importante pour montrer aux clients la
qualité de la matière première. Le pilote connaît parfaitement les produc-
teurs et il a assuré avec la société extérieure, chargée de la prise de vue et
de la réalisation, la production de ce document. Cette demande n’a pas été
formalisée sur les contrats d'interfaces. Il n’y a pas eu de problème de

réalisation.
Une attente d’un processus utilisateur peut-elle devenir

une nouvelle donnée de sortie ?
Oui. Il faut rappeler que les attentes, telles que nous suggérons de les
formuler dans cette approche, sont des besoins non satisfaits ou des
données de sortie qui posent problèmes dans leur utilisation par les
processus en aval. Les attentes pourraient d’ailleurs s’intituler «pistes de
progrès » par exemple. En conséquence, une attente exprimée au sujet
d’une donnée de sortie peut tout à fait devenir à son tour une nouvelle
donnée de sortie. Par exemple, un service réception de marchandises
compte dans sa liste de données de sortie les produits reçus et mis à dispo-
sition des acheteurs. Ceux-ci, à l’occasion d’une revue de processus avec
les fournisseurs, expriment le besoin d’être informés immédiatement lors
de l’arrivée de la marchandise commandée. Une nouvelle donnée de sortie
est donc créée qui s’intitule « information quotidienne de la livraison des
marchandises ».
Combien de données de sortie un processus doit-il

compter en moyenne ?
Il n’y a pas de réponse standard. Le nombre de données de sortie émises
par un processus n’a aucun rapport avec son volume d’activité. Par
exemple, un service (un processus) spécialisé dans les pratiques d’audits
internes aura quasiment une seule donnée de sortie qui sera le rapport
d’audit. Et cependant, ce processus peut faire travailler une vingtaine
d’auditeurs. L’expérience montre que le nombre de données de sortie
spécifiques d’un processus ne dépasse que rarement une vingtaine
d’unités. Ce nombre peut être augmenté par les divers formulaires ou
demandes de type administratif (demandes de congé, etc.) qui se retrou-
vent dans tous les processus. Si ces données de sortie de type administratif
sont trop nombreuses et encombrent les contrats d'interfaces, il conviendra
d’en faire une liste à part que chaque processus ajoutera en annexe à son
contrat d'interfaces.
Comment savoir exactement qui est client et qui est

fournisseur dans une transaction ?
Le principe de client/fournisseur semble parfois complexe à appréhender
car, dans une transaction, chacun peut avoir besoin d’éléments en prove-
nance de l’autre. Dans notre organisme, cette relation se simplifie à

l’extrême en adoptant la règle suivante :
– Lorsque toutes les données de sortie ont été identifiées, il suffit de
considérer que pour chacune d’entre elles, le processus qui en est à
l’origine est le fournisseur et celui qui la reçoit est l’utilisateur (le
client). Il ne faut pas réfléchir à partir de la transaction globale car
cela est parfois compliqué. Par exemple, un processus commercial
demande à un processus informatique de lui développer une nouvelle
application. Que cette demande soit orale ou écrite, elle constitue une
donnée de sortie du processus commercial. Le processus informa-
tique doit la prendre en considération. Mais le processus informa-
tique souhaite un cahier des charges détaillé pour réaliser un travail
efficace. Dans ce cas, il est possible de considérer cette demande
comme une donnée de sortie du processus informatique. Pour ce cas
précis, il est recommandé de formaliser cette façon de faire d’une
manière plus générale sur le contrat d'interfaces. Ainsi, dans les
contrats d'interfaces des processus de réalisation et de service, nous
trouverons entre autres données de sortie, des demandes d’interven-
tion auprès du processus informatique. Si ces demandes posent
problèmes, il y a tout lieu de penser que, dans la colonne «attentes
des utilisateurs », nous trouverons une demande de cahier des
charges détaillé de la part du processus informatique. Et enfin, nous
trouverons aussi dans les données de sortie du processus informa-
tique, une rubrique « développements sur demandes des
utilisateurs».
Autre exemple, dans une relation entre deux processus qui sont
« logistique » et « production », nous pourrions trouver « demande de
consommables» comme donnée de sortie du processus de production et
«fourniture de consommables» comme donnée de sortie du processus de
logistique.
Un dossier complet regroupant plusieurs documents

différents peut-il être considéré comme une seule
donnée de sortie ?
Oui. Cela peut simplifier la présentation d’un contrat d'interfaces. Par
contre, cette façon de faire demande que l’ensemble des documents du
dossier en question parte chez les divers utilisateurs au même moment. Par
exemple, et a contrario, le bureau d’étude d’une entreprise a regroupé les
informations relatives à la conception d’un nouveau produit dans un seul
document. Celui-ci est donc une donnée de sortie et il est transmis à
d’autres processus en fin de conception. Mais, il se trouve qu’un processus

particulier (pour faire des essais) a besoin d’une copie des informations
contenues sur la première page de ce dossier dans les premiers jours qui
suivent le lancement d’un nouveau projet. Dans ce cas précis, cette copie
doit être identifiée comme une donnée de sortie particulière et figurer à part
dans la liste des données de sortie, avec mention de son utilisateur spéci-
fique.
QUESTIONS RELATIVES AUX ATTENTES

DES UTILISATEURS
Doit-on faire figurer le client externe parmi les utilisateurs

de données de sortie dans un contrat d’interfaces?
Oui, bien que les contrats d'interfaces soient essentiellement destinés à
améliorer les relations internes entre les processus et les fonctions de
l’entreprise, il est avantageux de préciser en regard de chaque donnée de
sortie, dans la liste des utilisateurs, si le client en fait partie. Cela signifie
que la donnée de sortie en question est un lien direct entre l’organisme et
le client externe, via le processus en question. Cela permet, par analyse des
données de sortie de tous les processus, d’identifier l’ensemble des liens
qui unissent les clients et l’organisme. Cette connaissance est utile lorsque
nous souhaitons évaluer le niveau de satisfaction de nos clients. Celui-ci
dépend bien évidemment de la qualité de chacune des données de sortie
directement perçue par le client.
Données de sortie Utilisateurs Attentes Habilitations, etc.

Facture Clients/Compta
La colonne des attentes ne sera pas renseignée pour ce qui concerne le

client puisque cela est réalisé à une autre étape, très certainement avec une
autre méthode, lors d’une enquête de satisfaction clients par exemple ou de
toute autre technique d’évaluation de la satisfaction. Pour la préparation de
l’enquête, il sera alors très utile de connaître toutes les données de sortie
qui vont chez le client.
Dans la colonne «attentes utilisateurs», doit-on faire

figurer tout ce que les utilisateurs souhaitent ?
Il y a deux réponses possibles.
– Soit, le pilote du processus note uniquement les attentes non satis-
faites. Par exemple, si un dossier arrive souvent au dernier moment,
le fournisseur interrogé demande une date au plus tard de remise du
dossier. Cette demande figure alors dans la colonne « attente
fournisseur». Si de manière générale, les dossiers arrivent dans des
délais raisonnables, aucune attente n’est alors à signaler. Cette façon
de faire permet de simplifier les contrats d'interfaces et de les utiliser
à des fins d’amélioration seulement, ce qui est leur finalité essen-
tielle. Il conviendra alors que les propriétaires de processus fournis-
seurs élaborent par la suite des plans d’actions d’amélioration pour
répondre aux attentes exprimées par les fournisseurs et améliorer
ainsi régulièrement leurs données de sortie et aider leurs utilisateurs
à travailler plus efficacement.
– Soit le pilote du processus note toutes les dispositions qu’il doit
prendre pour fabriquer les données de sortie. Cette colonne «attentes
fournisseur» joue alors le rôle de procédure ou d’instruction écrite.
Elle précise les bonnes pratiques de travail interne du processus four-
nisseur pour chacune des données de sortie fabriquées. Cette façon
de faire entraîne un formalisme conséquent et mélange les données
de sortie (le QUOI) avec les méthodes de travail (le COMMENT).
Outre que cela complique les contrats d'interfaces, tout changement
de pratique de travail demandera une mise à jour du contrat d’inter-
faces et donc compliquera la gestion documentaire.
Personnellement, je préfère la première solution. Les pratiques de travail
des processus sont alors dissociées des contrats d'interfaces et formalisées
dans des procédures distinctes.
Peut-on refuser ou négocier les attentes des utilisateurs?

En principe non car toute l’organisation est basée sur le principe de la satis-
faction aux exigences des clients externes et à celles des clients (utilisa-
teurs) internes puisque c’est par la chaîne de déclencheurs/déclenchés que
se transmet la voix du client externe. En conséquence, satisfaire les attentes
des clients internes permet au bout du compte de satisfaire les clients
externes. Cependant, comme toute règle, celle-ci peut accepter des excep-
tions. Les discussions entre propriétaires de processus se font de toute
bonne foi et la négociation est bien entendu possible et même souhaitée. Il
peut être intéressant par exemple, que le client justifie sa demande en
expliquant les économies ou l’intérêt qu’il trouvera si ses attentes sont

satisfaites par son fournisseur. Il faut que l’action d’amélioration qui sera
engagée par le fournisseur apporte un progrès pour l’organisation globale.
Si cette demande oblige le fournisseur à un effort ou à une plus grande acti-
vité, encore faut-il qu’un bénéfice soit généré chez l’utilisateur.
Par exemple, dans un contrat d’interfaces entre la logistique et la produc-
tion, la logistique étant dans ce cas le fournisseur, la production attend que
les OF (Ordres de Fabrication) ne soient pas coupés en permanence en
deux ou trois lots séparés. La logistique essaie de discuter cette attente en
expliquant que ces scissions de lots se font pour répondre à des urgences
souhaitées par des clients. C’est donc pour la satisfaction des clients que la
logistique opère ainsi.
La réponse à trouver sera un compromis. On peut accepter des urgences
lorsque cela reste une exception vraiment exceptionnelle. Tout le monde
sait que les urgences perturbent les livraisons et risquent de mécontenter
d’autres clients. Car dans le cas contraire, non seulement la production
perdra en efficacité mais les retards de livraison risquent d’empirer et de
générer une baisse du niveau de satisfaction global des clients.
Pour résumer, il est possible de négocier pour une période proche car il est
souvent difficile de changer les pratiques trop brutalement mais le fournis-
seur s’engagera dans un plan d’actions progressif pour, in fine, satisfaire
pleinement aux attentes exprimées par ses utilisateurs. Par exemple, dans
le cas ci-dessus, la logistique s’engage sur un nombre de scissions de lots
maximum (comme deux par jour ou par semaine) avec des objectifs de
réduction sur six mois. Par exemple, deux scissions de lots par semaine
dans les trois prochains mois, puis un seul par semaine dans les trois mois
suivants puis aucune scission après six mois.
Histoire vraie
Dans une entreprise du secteur de la chimie, un processus «technique
produit» décide des spécifications techniques des produits fabriqués. Ce
sont des produits propres à l’entreprise. Il définit entre autres les tolérances
de fabrication. Un de ses processus utilisateurs est la production et, à l’oc-
casion d’une revue de processus, celle-ci demande à son fournisseur
d’élargir les tolérances afin qu’elle puisse réduire les quantités de produits
hors normes et améliorer ainsi ses performances. Cette demande est bien
évidemment inacceptable par le fournisseur. Elle est contraire à la politique
qualité de l’entreprise qui souhaite améliorer la qualité des produits fabri-
qués. Dans une situation de ce genre, en cas de refus d’un fournisseur, ce-
lui-ci pourra argumenter sa décision sur l’examen de la politique qualité et
sur les principes du management de la qualité qui reposent en général sur
la satisfaction du client.
Les utilisateurs des données de sortie peuvent-ils être

d’autres entités que des processus de réalisation
ou de support (service)?
Oui. Il peut y avoir la hiérarchie qui n’est pas pilote de processus. Un chef
de service sera en principe pilote (ou propriétaire de son processus) et, de
ce fait, exprimera les attentes de son processus à ses fournisseurs. Mais un
directeur technique qui n’a pas de rôle de pilote peut être à l’origine d’une
demande (un rapport ou une étude par exemple) et donc peut être utilisa-
teur de la donnée de sortie demandée.
Dans un autre ordre d’idées, un groupe de travail ou d’étude peut être
demandeur et/ou utilisateur de données de sortie. Par exemple, un compte
rendu de réunion de lancement d’un nouveau produit peut intéresser un
groupe de réflexion constitué sur un thème relatif à la conception et au
développement de nouveaux produits. Dans le contrat d’interfaces, il
conviendra alors de noter l’identité de l’utilisateur, par exemple GPI
(Groupe Progrès Imprimerie) et il conviendra ensuite de demander les
attentes éventuelles au pilote de ce groupe quant à la donnée de sortie dont
il est utilisateur.
Comment procéder quand les attentes d’un processus

utilisateur ne peuvent être satisfaites uniquement
par le processus fournisseur ?
Autrement dit quand le processus fournisseur dépend lui-même des infor-
mations ou des éléments qui lui sont transmis par ses propres fournisseurs.
Ce cas est fréquent et il constitue un des intérêts de la démarche par l’aval

et du principe de relation client/fournisseur en interne. En effet, tous les
processus sont reliés dans une chaîne d’activités qui part du client et qui va
au client. La réponse aux attentes d’un processus utilisateur doit parfois
générer une attente exprimée par le fournisseur à son propre fournisseur.
Par exemple, la liste des produits à expédier le lendemain est communi-
quée chaque début d’après-midi au magasin chargé des expéditions. Celui-
ci, dans le contrat d'interfaces de son fournisseur, exprime le besoin de
disposer de cette liste l’avant-veille au soir. La satisfaction à cette attente
lui permettrait d’avoir le temps de préparer les colis et d’étaler le charge-
ment des camions. Le gain de temps et d’argent est évident. Le processus
fournisseur est «l’administration des expéditions» qui, dans un premier
temps, répond qu’elle ne peut pas car elle dépend elle-même de la produc-
tion qui ne l’informe des expéditions qu’en fin de matinée. Ce processus
d’administration des expéditions doit donc à son tour exprimer ses attentes
et demander à ce que la production anticipe d’une journée son programme
de fabrication. Il est clair que cette demande est raisonnable car dans ce
cas, la production montre une mauvaise organisation en n’étant pas
capable de prévoir la veille ce qui sera produit le lendemain. Un effort est
manifestement à faire dans ce domaine. Bien entendu, ce cas est très
fréquent et il faut que la direction fasse pression pour que les attentes expri-
mées trouvent un écho chez les processus fournisseurs et que des actions
d’amélioration soient réellement mises en œuvre.
Doit-on répondre obligatoirement à une attente

d’un processus client ?
Non. L’expression des attentes des clients permet à chaque processus four-
nisseur d’identifier des pistes d’amélioration et d’engager des actions en ce
sens. Le mieux est souvent l’ennemi du bien, entend-on dire souvent. En
l’occurrence, ce proverbe conserve tout son bon sens. Il est possible,
lorsque les attentes ont été exprimées, de les classer par ordre d’importance
et de faire un choix parmi celles qui sont faciles à satisfaire, ou celles qui
sont urgentes ou bien encore celles qui apporteront une amélioration
conséquente des pratiques du client. Il est surtout important que chaque
processus s’engage dans des actions et que la relation client/fournisseur
s’améliore en permanence grâce à l’écoute des attentes et à une réponse à
quelques unes d’entre elles de manière continue. Le progrès est souvent
plus efficace s’il est permanent et régulier que s’il est discontinu.
Sur les contrats d’interfaces, le fournisseur peut par exemple classer les
attentes exprimées par ordre décroissant d’importance et surligner de fluo
les trois premières demandes auxquelles il s’engage à répondre.
QUESTIONS RELATIVES À L’IDENTIFICATION

DES PROCESSUS
La direction d’un organisme constitue-t-elle un processus

de management ?
Le ou plutôt les processus de management n’ont pas une forme ou une
expression définie. Les processus de management sont les règles et les
principes qui sont édictés pour piloter et maîtriser un organisme et lui
donner un avenir viable. Il serait possible de considérer que toutes les
règles sont regroupées dans un seul processus et que celui-ci serait effecti-
vement, dans ce cas, le processus de la direction. Mais il est possible
également de faire plusieurs familles de processus et chaque famille sera
considérée comme un processus de management et le pilote désigné sera
le dirigeant en personne. Comme nous l’avons montré dans le chapitre
consacré aux processus de management, une pratique simple est de classer
les processus en familles conformes aux chapitres de la norme ISO 9001.
Nous aurons ainsi par exemple une famille processus de management
« responsabilité de la direction », qui correspond au chapitre cinq et une
autre « amélioration », qui correspond au chapitre huit.
Le processus qualité est-il un processus et dans quelle

catégorie peut-on le classer ?
Dans notre approche, le service qualité est bien entendu un processus
puisqu’il occupe une place sur l’organigramme. Nous le classons dans la
famille « processus de service » ou « processus support » selon l’appella-
tion que l’on a choisie. Cependant, il arrive que des données de sortie de
ce processus qualité soient redondantes avec celles de processus de mana-
gement, en particulier le processus relatif à l’amélioration continue. Par
exemple, les rapports d’audit sont souvent positionnés comme des données
de sortie du processus qualité. Or, selon notre principe d’élaboration des
processus de management, les rapports d’audit devraient figurer dans le
processus «amélioration». Le problème n’est pas bien grave. Si dans un
organisme, la direction a délégué l’amélioration au processus qualité, le
processus de management disparaît au bénéfice de celui de la qualité. Il est

possible au demeurant de conserver les deux à condition que les données
de sortie soient partagées entre chacun d’eux et qu’il n’y ait pas la même
donnée de sortie dans les deux processus.
Une procédure peut-elle être confondue avec un

processus ?
Absolument pas! Ce n’est pas du tout la même chose et il convient simple-
ment de se reporter aux définitions normalisées pour distinguer la diffé-
rence. Un processus est : «un ensemble de ressources et d’activités liées
qui transforme des éléments entrants en éléments sortants». Il s’agit d’un
assortiment, d’une association de ressources (des personnes et du matériel)
qui travaillent et qui produisent quelque chose. Une procédure décrit une
activité. Une procédure est donc une méthode de travail mise en œuvre par
un processus (des ressources) dans le cadre de la transformation des
données d'entrée en données de sortie. Une procédure n’est pas un
ensemble de ressources et un processus n’est pas une pratique de travail.
Ces deux définitions doivent absolument être claires dans tous les esprits
afin qu’aucune confusion ne soit possible.
Quels processus peut-on classer dans la catégorie

«processus clef» ou «processus majeur» ?
Dans le référentiel ISO 9001, la norme demande d’identifier les processus
«…nécessaires au système de management de la qualité…» et, pour ces
processus, de mettre en place une organisation destinée à les maîtriser. Il
n’est pas question, au regard de la norme, d’identifier tous les processus
mais seulement ceux qui sont considérés comme importants pour l’organi-
sation. C’est ce choix qui rend l’approche processus classique (transver-
sale) difficile car rien ne nous aide à déterminer cette notion d’importance.
En ce qui concerne les activités de réalisation ou de support, nous pouvons
sans nous tromper beaucoup, ranger les processus de production dans cette
catégorie. Les activités liées à la réalisation du service sont, par essence
même, très importantes. Ensuite, cela dépend un peu de la politique qualité
et des choix stratégiques de développement de l’organisme. Si par
exemple, celui-ci s’appuie sur la compétence de ses personnels, la gestion
des ressources humaines devient bien évidemment un processus majeur. Si
l’innovation est un élément fort de développement, alors la conception
devient un processus majeur. Si la maîtrise des délais et la réactivité condi-
tionnent fortement la satisfaction des clients, alors la logistique devient un
processus majeur. Il n’y a pas de règle préétablie pour faire ce choix et
opérer ce classement. Nous pouvons aussi sans nous tromper considérer les
activité liées au management de la qualité comme un processus majeur
également.
En ce qui concerne les processus de management, nous devons y ranger
l’amélioration et la gestion du système de management de la qualité. Le
référentiel ISO considère aussi que la communication est un processus et à
ce titre elle doit figurer quelque part dans l’inventaire de nos processus
majeurs.
Une activité comme l’intelligence économique

est-elle un processus ?
Si l’organisme la pratique comme une nécessité, alors elle est effective-
ment un processus. Les règles et méthodes qui permettent de l’organiser et
de la maîtriser doivent être définies. Auparavant, les données de sortie (ce
que l’on attend en terme de résultats) seront identifiées. Par exemple, des
rapports, des messages, des publications, etc.
L’intelligence économique concerne a priori plusieurs processus et sera
certainement un processus de type «management». Mais il est possible,
dans un organisme de grande taille, de mettre en place un service IE et, en
conséquence, de disposer d’un processus de type « support » avec des
ressources spécialement affectées à ces activités de veille.
Un processus est-il toujours une fonction ou un service

de l’organigramme ?
Non. Dans la plupart des cas, avec notre approche par l’aval, il est vrai que
le découpage en fonctions correspond au découpage en processus. Comme
nous l’avons évoqué auparavant, cette convention a l’immense avantage
de couvrir toutes les activités de l’organisme, de respecter le principe de
responsabilité des ressources des pilotes de processus et de simplifier
l’inventaire des processus (il est déjà établi par l’organigramme). Mais il
se peut que des processus apparaissent sans que cela soit déjà visible dans
l’organigramme. Par exemple dans les petites structures de type TPE (Très
Petites Entreprises), les responsables ont, comme on dit, plusieurs
casquettes. Ils assurent à la fois le commercial, la technique et les achats
par exemple. Dans ce cas, il est possible d’établir une cartographie de prin-
cipe qui fait apparaître toutes les fonctions, y compris celles qui sont mana-
gées par les mêmes personnes. Un autre cas de figure peut également
apparaître lorsque des fonctions sont partagées. C’est le cas des achats que
nous avons déjà évoqués. Plusieurs services sont habilités à acheter. Dans
un organisme de formation ou de conseil, plusieurs personnes appartenant
à des services différents sont habilitées à vendre. Dans ce cas, il est

possible de faire figurer ces processus soit comme un processus de
réalisation, soit comme un processus de management.
En théorie, ce qui caractérise un processus est sa finalité. Nous identifions
d’abord un besoin, une finalité à atteindre, une raison d’être et ensuite nous
identifions ou nous attribuons des ressources pour que cette finalité soit
assurée. Ces ressources peuvent être spécifiques à un processus ou parta-
gées entre plusieurs. Par exemple, une réflexion sur la nécessité, pour un
organisme de développer des nouveaux produits ou des produits qui lui
sont propres, est une réflexion stratégique qui décide de la nécessité
d’innover. Si cette décision est entérinée, l’organisme se préoccupe ensuite
d’affecter les ressources nécessaires à mettre en œuvre les activités qui lui
permettront d’atteindre les buts souhaités.
Le secrétariat est-il un processus ?

Cela dépend des activités qui sont réalisées par cette fonction ou ce service.
Bien entendu, la question se pose uniquement dans le cas où cette activité
est regroupée au sein d’un service. Lorsque le secrétariat se compose d’une
ou deux personnes dans un service commercial par exemple, il n’y a pas de
processus spécifique. Dans le premier cas, les activités de secrétariat sont
bien souvent très diverses. L’on confie à ce service des tâches de factura-
tion, de mise au propre de devis, de recherche documentaire, etc. qui n’ont
souvent en commun que le fait qu’elles soient réalisées par des personnes
éminemment polyvalentes et débrouillardes. La finalité de telles activités
diversifiées n’est pas facile à définir et, en conséquence, un processus de
secrétariat est difficile à positionner sur une cartographie. La solution la
plus simple est de considérer qu’il n’existe pas en tant que tel et que ses
ressources sont affectées provisoirement aux processus pour lesquels ce
service de secrétariat travaille. C’est un exemple qui montre que, parfois,
il y a des différences entre organigramme hiérarchique et cartographie
générale des processus.
Histoire vraie
Un processus «laboratoire» d’un centre technique établit un rapport d’ana-
lyse. Ce rapport est enregistré sur une base de données par le personnel
du laboratoire. Deux à trois fois par jour, un autre processus (administratif)
édite les rapports à l’usage des clients. Les retards d’édition ne posaient
pas de problème au laboratoire puisque celui-ci n’était pas responsable de
cette tâche. De son coté, le processus administratif avait beaucoup
d’autres activités de type «secrétariat», comme évoqué au paragraphe pré-
cédent. Cette situation n’étant pas satisfaisante pour les clients, la question
s’est donc posée sur la valeur ajoutée de l’administratif. Il n’y en avait pas,
la mise au propre n’étant pas réellement considérée comme telle. Il a donc
été décidé que le travail de mise au propre devenait une activité du pro-
cessus «laboratoire» même si la personne qui réalisait cette tâche appar-
tenait au service administratif. Il a été considéré que cette ressource était
allouée provisoirement au laboratoire. Ainsi, le rapport édité devenait une
donnée de sortie du laboratoire et celui-ci prenait donc la responsabilité
de sa diffusion et des retards éventuels.
A quels processus attribuer des données de sortie issues

de bases de données informatiques ?
Voir plus loin réponse concernant les systèmes ERP
Y a-t-il un nombre de processus maximum à ne pas

dépasser ?
Nous entendons parfois, à l’occasion d’audits tierce partie par exemple,
des auditeurs qui affirment que le nombre de processus identifiés dans
l’entreprise est trop élevé et qu’il convient de simplifier l’organisation en
réduisant ce nombre à trois ou quatre seulement. Leur intention est certes
louable, mais je pense qu’il existe des pistes de simplification plus perti-
nentes et plus intelligentes. Le nombre de processus ne se décrète pas de
façon péremptoire. Il dépend de l’organisme, de sa taille, de la nature de
ses prestations, etc. Cette remarque est aussi appropriée que si elle concer-
nait par exemple un parc conséquent d’appareils de mesure et que le même
auditeur s’exclame qu’il y en a trop et qu’il faut en réduire le nombre pour
simplifier l’organisation. Le nombre d’appareils de mesure est ce qu’il doit
être, comme le nombre de processus. Si nous souhaitons améliorer les
interrelations entre toutes les fonctions (processus) de l’organisme nous
devons prendre en considération l’ensemble des sous-systèmes qui compo-
sent l’organisation.
Peut-on regrouper des processus pour en réduire le

nombre et disposer d’une cartographie plus claire ?
C’est possible quand des processus ont des finalités très proches et quand
les pilotes sont les mêmes personnes (dans les TPE par exemple). Si les
pilotes sont des personnes différentes, il vaut mieux conserver l’identifica-
tion de processus distincts. L’approche processus et les contrats d'inter-
faces ont pour but d’améliorer les interrelations entre les fonctions. Si nous
les groupons inconsidérément, nous pouvons ignorer de réels problèmes de
communication et passer à côté de pistes intéressantes d’amélioration. Si
nous groupons des processus qui ont des finalités différentes, il sera diffi-
cile d’en tirer une raison d’être pertinente et cohérente. Par exemple, il est
logique de trouver chez des commerçants et chez des artisans des
bouchers/charcutiers ou des boulangers/pâtissiers mais il est moins courant
de rencontrer des cordonniers/charcutiers ou des restaurateurs/maçons.
Un processus externe (sous-traitant par exemple)

doit-il figurer sur la cartographie générale?
A priori ce n’est pas utile. Nous pouvons cependant indiquer les sous-trai-
tants sur la cartographie en les positionnant à l’extérieur du périmètre
comme nous l’avons fait sur certains schémas montrés précédemment. Si
le sous-traitant fait partie d’une chaîne de processus, il toujours possible
également de le faire figurer dans le périmètre avec un symbole graphique
(couleur) montrant qu’il n’appartient pas à l’organisme.
Est-il possible de procéder à la création d’un nouveau

processus ?
Oui. La procédure (la manière de faire) n’est pas compliquée. Il suffit
d’abord d’identifier la finalité du processus, puis d’identifier les données
de sortie attendues et enfin d’identifier les utilisateurs. En toute logique,
nous devrions commencer par là car un processus ne peut être créé que
pour répondre à une demande ou à des besoins identifiés. Ce genre d’exer-
cice est intéressant car il montre concrètement ce qui doit être produit (la
valeur ajoutée) d’un processus. Cela peut éviter de créer des entités qui ne
servent pas à grand-chose. Dans une entreprise, il a été décidé de créer un
processus «satisfaction client» à la suite d’une démarche de mise en œuvre
d’un système de management de la qualité ISO 9001. Il a fallu d’abord
savoir qui serait utilisateurs des informations relatives à la satisfaction des
clients et ce que ces processus en feraient (quelles actions conduiraient-
ils?). Puis il a fallu préciser sous quelle forme ces informations sortiraient
de ce nouveau processus.
Un processus peut-il être toujours client d’un autre

processus ?
Non, la relation client/fournisseur en interne ne définit pas la relation d’un
processus par rapport à un autre processus de manière globale ou absolue.
La relation client/fournisseur en interne ne se conçoit que pour une donnée
de sortie déterminée. Un processus peut être fournisseur pour une relation
et client pour une autre. C’est pour cette raison que les systèmes de relation
client/fournisseur en interne qui essaient d’être mis en œuvre de façon
globale dans une organisation ne marchent pas très bien car tout le monde
est à la fois client et fournisseur de tout le monde ce qui fait que la relation
ne change pas.
Par exemple, la maintenance n’est pas le fournisseur de la production ni
l’inverse. Le cahier des charges est fourni par la production (fournisseur) à
la maintenance (client) et l’intervention est du ressort de la maintenance
(fournisseur) pour la production (client).
QUESTIONS RELATIVES AUX

INTERRELATIONS ENTRE LES PROCESSUS
Une procédure interne à un processus peut-elle demander

une action à un autre processus ?
Il faut éviter cette situation. Par exemple, nous pourrions envisager qu’une
procédure de revue de projet, élaborée par un bureau d’études, demande au
service qualité de faire un rapport d’échantillons initiaux ou demande à la
production de réaliser des prototypes, etc. Cette situation est un cas clas-
sique des anciennes procédures des systèmes d’assurance qualité ou des
anciens systèmes de management. Lorsqu’un processus élabore une procé-
dure, il doit limiter les champs de cette procédure à ses ressources internes
et ne doit en aucun cas impliquer d’autre processus. L’implication des
autres processus se fera par le biais de demandes formulées comme des
données de sortie de ce processus et adressées aux processus concernés.
Dans l’exemple évoqué ci-dessus, le bureau d’étude adressera au service
qualité une demande d’échantillons initiaux, cette demande étant forma-
lisée ou non. Ce même bureau adressera à la production une demande de
prototype. Cette demande se fera soit au coup par coup, soit sera intégrée
dans un planning.
Seules les procédures générales considérées comme des règles de manage-

ment, et donc issues des processus de management (élaborées par l’équipe
dirigeante), peuvent concerner plusieurs processus. Elles sont, comme
dans le cas évoqué pour les achats dans le paragraphe précédent, des
données de sortie de ces processus de management.
Faut-il supprimer les logigrammes qui montrent

les processus transversaux et qui sont bien utiles
pour faire comprendre la mécanique de l’entreprise
aux nouveaux embauchés ?
Nous avons expliqué qu’il est illusoire de vouloir représenter sur un seul et
même document le fonctionnement complet d’un processus transversal en
raison des changements fréquents qui affectent de plus en plus les activités
de nos organismes et qui de ce fait obligent à des mises à jour permanentes
de ces documents (qui sont des procédures générales de fonctionnement).
Il s’ensuit généralement que ces documents ne sont pas représentatifs de la
réalité (ils ont toujours une mise à jour de retard) ou bien qu’ils demandent
des ressources importantes pour la mise à jour (travail sans aucune valeur
ajoutée). Dans tous les cas, ces représentations de processus transverses
n’apportent rien en terme d’efficacité aux organismes qui pratiquent ce
type de cartographie.
Par contre, il est vrai que la lecture de ces documents apporte (quand ils ne
sont pas trop complexes) un éclairage sur le fonctionnement de l’orga-
nisme. Il est donc possible de les conserver mais comme une information
sans valeur de procédure. Il convient de rappeler qu’une procédure doit
être comme une recette de cuisine ou comme un règlement, c'est-à-dire une
loi absolue que nous devons appliquer et respecter sous peine de problèmes
graves. Si une procédure dit que nous devons procéder à la stérilisation du
matériel chirurgical avant toute opération, il n’est pas admissible de passer
outre cette recommandation. Ce principe est donc valable pour toutes
procédures (avec des niveaux de risques différents). Aujourd’hui, nous
avons pris l’habitude d’avoir des procédures qui ne sont pas respectées
parce qu’elles ne sont pas à jour sans que cela ne nous dérange outre
mesure. Ce n’est absolument pas normal. Il vaut mieux réduire le nombre
de procédures et le limiter à celles qui sont absolument nécessaires et faire
en sorte que ces procédures soient strictement respectées.
Pour en revenir aux descriptifs de processus transverses (logigrammes ou
procédures générales), ils peuvent être déclarés purement informatifs. Ils
peuvent jouer le même rôle qu’une vidéo de présentation d’un organisme
par exemple, dans laquelle une erreur n’a pas d’importance. Si cette vidéo
précise que notre effectif est de cent trois personnes et que, depuis sa créa-
tion, nous sommes passés à cent dix personnes, cela ne nuit en rien à la
compréhension du spectateur qui s’informe de nos activités.
Un processus peut-il être caractérisé par plusieurs contrats

d'interfaces ?
Oui, cela peut arriver bien que ce soit assez rare. Par exemple, dans une
école privée, la direction à mis en place un processus nouveau qu’elle a
intitulé «développeurs». Ce processus compte dix personnes, tous respon-
sables de projets pédagogiques divers et qui correspondent à des forma-
tions en alternances diverses comme par exemple dans l’immobilier, dans
le commercial ou dans l’assistanat de direction. Ce processus est unique
sur la cartographie générale car le principe de fonctionnement d’un déve-
loppeur (sa finalité, sa mission, ses indicateurs, etc.) est unique mais
chaque développeur dispose de son propre contrat car ses données de sortie
sont parfois différentes selon que son projet de formation concerne
l’immobilier ou le commercial. Les utilisateurs peuvent être également
différents d’un type de formation à un autre.
Dans un atelier de fabrication, doit-on distinguer les

différents types de produits fabriqués comme autant de
données de sortie à préciser dans le contrat d'interfaces ?
Cela dépend de la complexité et des diverses typologies de produits qui
peuvent être fabriqués dans un atelier. La solution la plus simple consiste
à identifier une seule donnée de sortie qui sera intitulée «pièce fabriquée»
ou «produit fabriqué», sans distinguer le type de pièce ou de produit. Cela
présente l’inconvénient de ne pas pouvoir remplir la colonne « qui sait
faire?» car la compétence dépend souvent de la complexité des produits
fabriqués et plusieurs niveaux de compétences sont parfois nécessaires
pour produire toutes les catégories de prestations d’un atelier. Si cette solu-
tion est choisie, il conviendra de compléter les contrats d’interfaces par des
matrices de compétences qui identifient ces niveaux de compétences par
catégorie de produits ou de pièces fabriqués. Je préfère cette seconde solu-
tion afin de ne pas alourdir les contrats d'interfaces. Nous les utilisons
parce qu’ils sont pratiques pour identifier en même temps les compétences
et les habilitations mais cela n’est pas leur rôle principal (qui demeure
l’amélioration des interrelations). Lorsque ces éléments annexes devien-
nent trop importants et encombrent les contrats d'interfaces, il faut les
traiter à part dans des documents séparés et spécifiques.
Un processus de service (support) est-il toujours déclenché

par un processus d’opération (réalisation) ?
Non. Pour la plupart d’entre eux, la théorie voudrait que cela soit vrai. Par
exemple, un processus «informatique» intervient sur demande d’un utili-
sateur. Un processus qualité intervient sur demande d’un utilisateur qui
souhaite mettre en place une technique de résolution de problème. Dans la
réalité, il y a plusieurs autres types de relations. D’abord parce que les
processus ne fonctionnent pas encore systématiquement avec un mode de
relation client/fournisseur en interne et qu’ils réalisent des tâches qui ne
sont pas demandées par les processus de réalisation. Ensuite, et c’est un cas
plus normal, parce que les interventions des processus de service sont assu-
jetties à des règles de management décidées par les directions. Par
exemple, un processus de contrôle de gestion ou administratif interviendra
sans que cela soit demandé par un processus de réalisation. Sur la cartogra-
phie générale, il est difficile de montrer ces subtilités et de ce fait, il est plus
simple de préciser que tous les processus de services sont déclenchés par
ceux de réalisation. Cette cartographie ne peut, je le répète, prendre en
considération tous les cas de figures possibles et imaginables. Ce n’est pas
important car le détail des vraies relations sera réellement déterminé dans
les contrats d'interfaces.
Peut-on faire plus de contrats d'interfaces que de

processus identifiés sur la cartographie générale ?
Oui. Il faut qu’il y ait au moins le même nombre de contrats d'interfaces
que de processus mais il peut y avoir plus de contrats d'interfaces que de
processus. Nous avons déjà évoqué un cas où cette situation apparaît, celui
du travail en plusieurs équipes ou celui du processus «développeurs» dans
l’école privée. Il est d’autres cas qui abondent dans ce sens. Par exemple,
dans le cas ou un processus de production se découpe en plusieurs ateliers
(sous-processus) qu’il est difficile d’ordonner selon une relation déclen-
cheur/déclenché car tous travaillent indifféremment les uns avec les autres
dans n’importe quel ordre. Dans ce cas, il peut être plus simple de ne faire
figurer sur la cartographie générale que le processus principal (la produc-
tion) et de faire autant de contrats d'interfaces qu’il y a de sous-processus
dans ce processus principal.
Le service qualité est-il responsable de la mise à jour

des contrats d'interfaces ?
Non, sauf du sien. Les contrats d'interfaces sont en quelque sorte les cata-
logues des processus et doivent être mis à jour régulièrement au fur et à
mesure que des demandes nouvelles sont souhaitées par des utilisateurs.
Chaque pilote a donc la charge de cette mise à jour. Les documents peuvent
être audités lors des audits de processus.
La cartographie doit-elle montrer toutes les relations entre

tous les processus ?
Non, cela est rigoureusement impossible car le nombre d’interrelations
entre processus est quasiment infini. Une cartographie qui aurait cette
ambition serait illisible. Dans notre approche, la cartographie ne propose
qu’un type de relation, celui de déclencheur à déclenché. C’est une
convention qui met l’accent sur l’importance des liens entre processus et
qui signale de manière plutôt symbolique le caractère particulier de cette
relation privilégiée. Il convient d’expliquer que les interrelations seront
précisées sur les contrats d’interfaces.
Comment établir la cohérence et la correspondance entre

données d'entrée et données de sortie ?
Cette correspondance n’est assurée que si la liste des processus est finie
(exhaustive) ce qui n’est pas le cas de nombreuses approches dites
« transversales ». En effet, dans ces derniers cas, comme nous sélec-
tionnons les processus «clefs», il se peut que certaines données de sortie
ne trouvent pas de processus utilisateurs dans la liste proposée. À l’inverse,
il est possible que des données d'entrée n’aient pas de parents identifiés
(celui-ci ne figure pas dans la liste établie) et qu’elles soient oubliées.
Comme il est important de vérifier que nous n’avons pas oublié de lien
entre les processus, nous suggérons d’établir un tableau de correspondance
entre les processus, du type de celui qui nous a été soumis par un client. Il
est reproduit avec l’aimable autorisation de Philippe Garcia de MICRO
MEGA.
Transport€ur
A gauche se trouvent deux listes identiques d’interrelations qui sont

appelée d’une part «données d'entrée» puis ensuite «donnée de sortie».
Les processus figurent dans la partie centrale. Les coches sont en forme de
flèche et cela signifie que les élément listés dans la première partie entrent
dans les processus identifiés et que les éléments situés en partie basse
sortent de ces mêmes processus. Chaque processus voit ainsi ses données
d'entrée et ses données de sortie identifiées. Cela permet de ne pas oublier
qu’une sortie d’un processus est toujours une entrée dans un autre.
Comment modifier une cartographie lorsqu’un processus

est supprimé ?
L’existence de contrats d'interfaces est intéressante dans ce cas comme
d’ailleurs dans toute forme de réorganisation en général. En effet, les
risques inhérents à ce genre de situation sont de supprimer indûment des
activités qui ont une utilité mais qui ne peuvent plus être effectuées par
manque de moyens ou plus simplement parce qu’elles ont été oubliées
dans la réorganisation. Il suffit de distribuer les données de sortie du
processus supprimé dans les autres processus en activité.
L’approche processus peut-elle être une base de travail

pour la mise en œuvre d’un système de type ERP ?
Les ERP sont essentiellement des systèmes de traitement de l’information.
Le principe est de disposer d’une base de données unique dans laquelle
nous avons rassemblé toutes les informations qui sont nécessaires au fonc-
tionnement efficace de l’entreprise et d’un calculateur qui transforme les
éléments de la base en informations élaborées. Un des problèmes que
l’informatique a généré dans les entreprises est l’anonymat de l’informa-
tion. Souvent, quand nous nous renseignons sur l’origine d’une informa-
tion, nous nous entendons répondre qu’elle vient du système, de la GPAO,
de l’informatique ou plus couramment de la bécane. La notion de respon-
sabilité est un des principes immuables de toute organisation performante.
Etre responsable c’est avoir le souci de l’élément dont on assume la
responsabilité, c’est en garantir la qualité. En ce sens, chaque processus est
responsable de ses données de sortie. Une information est une donnée de
sortie. Il faut donc impérativement l’attribuer à un processus du système,
autrement dit à un territoire. Mais pour qu’une information puisse être
considérée comme une donnée de sortie, il faut d’abord et au préalable
qu’elle soit une donnée d’entrée d’un processus utilisateur, c’est-à-dire un
besoin exprimé par un autre territoire de l’organisme. Les territoires expri-
mant leurs besoins le font en fonction des attentes des clients externes et
aussi en fonction de la stratégie de développement de la société et de sa

politique marketing.
Données de sortie
indirectes
Calculateur
Besoins en
informations
Client
Données de sortie
directe
Le traitement de l’information
et les processus
Le schéma des étapes de l’analyse peut être le suivant :

– Quels sont les partenaires extérieurs qui attendent des prestations de
notre part (par exemple les clients, les fournisseurs, l’État, le siège
de la société, etc.)?
– Quels sont les processus de premier niveau qui sont au contact de ces
partenaires extérieurs?
– Quelles sont les attentes de ces partenaires extérieurs à qui nous four-
nirons de l’information ou des prestations?
– Quelles sont les attentes des processus de premier niveau? De quoi
ont-ils besoin pour répondre aux attentes des partenaires extérieurs
et satisfaire la politique du management?
– Quels processus (territoires) doivent fournir ces données d’entrées?
– Y a-t-il un traitement de l’information entre la sortie des territoires
fournisseurs et l’entrée des territoires clients?
L’informatique (le calculateur) est en fait, dans ce contexte, une interface
sans responsabilité entre un fournisseur et un utilisateur d’informations.
C’est cet interfaçage qui rend anonyme l’information sortant de la
machine. Par exemple, un calcul de besoins (données de sortie de machine)
ne peut être attribué à aucun territoire. Il est le résultat d’un savant calcul
effectué à partir d’informations disponibles dans la base et qui ont été
renseignées par plusieurs processus territoires. L’un d’eux a donné le
stock, un autre a fourni les prévisions de ventes, un troisième la charge des
machines, un quatrième encore autre chose, etc.
Pour la mise en place d’un ERP ou de tout autre système complexe infor-
matique, l’approche processus peut être une base de travail. La démarche
présentée ci-dessus peut être entreprise lorsque la cartographie est
terminée.
Chaque processus chargé de répondre aux besoins extérieurs identifie ses
propres besoins et établit son cahier des charges exprimé simplement en
données d’entrées.
Ces données d’entrées sont ensuite, soit des données de sorties directes de
processus amont (fournisseurs), soit des données de sortie calculées par la
machine. Dans ce dernier cas, une analyse peut être faite pour déterminer
l’algorithme de calcul ou, dans le cas où l’algorithme est déjà établi, pour
déterminer les informations nécessaires à entrer dans la base. Celles-ci
doivent alors être demandées aux processus adéquats et compétents et
devenir ainsi des données de sorties répertoriées et maîtrisées. Les inter-
faces entre processus sont des éléments à géométrie variable et il
conviendra que chaque fournisseur développe, avec ses utilisateurs, des
contacts fréquents pour ajuster sa production à la demande, comme un
commerçant revoit son catalogue chaque année.
QUESTIONS RELATIVES À LA MAÎTRISE

DES PROCESSUS
Comment lier les divers documents du nouveau système

de management de la qualité dans une structure générale
documentaire ?
Dans notre approche processus, le document à la base de l’organisation est
la cartographie générale des processus. C’est le sommet de notre structure
documentaire. Nous pouvons, soit partir de ce document en tant que tel,
soit partir du manuel qualité dans lequel la cartographie est en principe
intégrée.
Sous la cartographie, à l’étage inférieur, nous trouvons les contrats d’inter-
faces. La cartographie générale nous apprend précédemment que chaque
processus identifié et montré dans la cartographie est caractérisé par un
document intitulé contrat d'interfaces.
Sous les contrats d'interfaces, nous trouvons les procédures. Celles-ci sont
mentionnées sur les contrats d'interfaces dans la rubrique « documents
attachés».
Nous y trouvons aussi les enregistrements qui sont pour la plupart des
données de sortie du processus en question.
Et enfin sous les procédures, nous trouvons tous les autres documents
divers qui complètent le cas échéant lesdites procédures.
Un petit schéma pour imager cette structure :
Manuel qualité Cartographie
Contrat d’interfaces n° 1
Procédure n° 1
Procédure n° 2, etc.
Structure documentaire
d’un nouveau SMQ Enregistrement n° 1
Enregistrement n° 2, etc.
Contrat d’interfaces n° 2
Contrat d’interfaces n° x
Faut-il lier chaque donnée de sortie à une éventuelle

procédure expliquant les pratiques de travail ?
Non. Une donnée de sortie est le résultat d’une activité et en conséquence,
il est possible de décrire et de formaliser les bonnes pratiques nécessaires
à réaliser une donnée de sortie conforme aux attentes des utilisateurs. Mais
il faut se rappeler que l’écriture des bonnes pratiques nécessite ensuite une
mise à jour permanente en fonction de l’évolution de ces pratiques, que
nous avons le droit de nous appuyer sur les compétences des personnels
pour éviter de tout écrire. L’écriture de procédures n’évite pas forcément
les erreurs.
Si le pilote d’un processus le juge nécessaire, une procédure peut donc être
écrite pour documenter la fabrication d’une donnée de sortie et dans ce cas,
la procédure en question sera mentionnée dans la colonne « document
attaché» du contrat d'interfaces. Il se peut qu’une procédure interne à un
processus ne puisse être attachée à une donnée de sortie. C’est le cas par
exemple d’une procédure de gestion des ressources internes du processus.
Il conviendra alors de signaler ce document dans une liste générale située
dans une nouvelle rubrique à ajouter dans les contrats d’interfaces. Il est
même possible, comme nous l’avons déjà suggéré précédemment pour
simplifier la présentation des contrats d'interfaces, de supprimer la colonne
«documents attachés» et de faire figurer tous les documents en question
dans cette rubrique générale située, par exemple, en bas de page des
contrats d'interfaces.
Comment lier les compétences aux données de sortie

des processus ?
Pour aborder le sujet de la maîtrise des compétences dans cette approche
processus, nous avons proposé d’identifier pour chacune des données de
sortie les noms des personnes habilitées à valider chacune des données de
sortie. Ces noms figurent dans une colonne intitulée « qui sait faire? ». Le
principe de remplissage de cette colonne est d’y préciser l’identité de
toutes les personnes qui sont capables de produire les données de sortie de
manière autonome. Par exemple, pour une donnée de sortie « facture »,
nous indiquerons les noms des personnels capables de faire une facture et
qui ont, bien entendu, l’autorisation de le faire. Autre exemple, pour une
donnée de sortie « rapport de contrôle » nous indiquerons les personnes
qui effectuent la tâche et qui rédigent le rapport. Si une tierce personne ne
fait que la mise au propre du rapport, il est évident que le nom qui figurera
dans la colonne « qui sait faire ? » est celui du responsable qui valide le
rapport. Pour les processus qui disposent de ressources nombreuses et
importantes, il est possible de décider d’élaborer un document à part, de la
forme d’un tableau à double entrée, une matrice de compétences par
exemple, qui associera les données de sortie du processus et les noms des
personnels du processus.
Ci-dessous un exemple de matrice de compétences d’un processus :
Données de Alex Robin Isa- Marcel Lenny Tara Zazie Mélo- Auré-
sortie belle die lie
Priorité de X
livraison
Faisabilité nou- X X X
veaux produits
CR de revue de X X X
projets
Rapports X X X X X
d’essais
Demandes de X X X X X X
prototypes
Facturation X X
clients
Demandes X
d’achats
Fiches techni- X X X X X
ques
Spécifications X X X X
d’essais
Dans les matrices de compétences, plusieurs personnes

peuvent-elles être habilitées à prendre des décisions ?
Si les décisions concernent des sujets différents, pourquoi pas ! Mais il
convient de montrer une seule donnée de sortie par type de décision. De
nombreux problèmes sont constatés très souvent suite à des décisions
contradictoires prises par plusieurs personnes. Il ne peut y avoir qu’un seul
chef sous peine de confusion. Les matrices de compétences et le contrat
d'interfaces servent à détecter parfois ce genre de problème. Par exemple,
dans un processus commercial, une donnée de sortie intitulée «priorité au
client» était attribuée à tous les responsables commerciaux de secteurs.
Cela paraissait logique car chacun d’eux devait avoir le droit de décider
quels clients seraient servis en priorité selon les urgences et les accords
passés. Or, après réflexion et sur la base du principe du commandement
unique, il s’avérait que cela engendrait des conflits entre les commerciaux
car chacun souhaitait bien entendu privilégier ses propres clients, parfois
au détriment de ceux des autres responsables commerciaux des autres
secteurs.
De plus, ce genre de décision ne doit pas appartenir au processus commer-
cial mais bien au processus logistique qui connaît tous les accords passés
avec les clients et dont la finalité est de les respecter. En cas de problème
particulier ou d’urgence, le responsable commercial qui souhaite modifier
un planning ou un délai de livraison doit prendre contact avec le pilote du
processus logistique pour décider d’autres priorités. Mais en tout état de
cause, c’est bien le processus logistique qui génère cette donnée de sortie
décisionnelle.
Est-il nécessaire de définir les ressources afférentes à un

processus ?
Il est bien sûr nécessaire que le responsable d’un processus définisse les
ressources dont il a besoin pour réaliser l’activité qu’on lui a confiée ou
pour atteindre les objectifs qu’on lui a assignés. Ces ressources doivent
même se discuter et se négocier avant de démarrer l’activité. Mais, est-il
besoin de décrire ces ressources dans un document de type « contrats
d'interfaces» qui caractérise un processus? Personnellement, je pense que
cela est inutile. Il convient que le pilote d’un processus discute de l’attri-
bution de ses ressources mais il doit disposer d’une certaine latitude pour
les agrandir ou les réduire sans autorisation. Il s’agit d’une question de
confiance entre la hiérarchie (la direction) et le responsable de processus.
Aujourd’hui, l’environnement est souvent variable, il faut savoir répondre
à des situations imprévues et à des impondérables et il est souvent néces-
saire que le responsable de processus ajuste ses ressources en fonction des
demandes de ses clients et en fonction des contraintes de son environne-
ment. Un inventaire documenté permanent et mis à jour ne sert à rien. Il
n’y a pas lieu de décrire les ressources sur les contrats d'interfaces ou sur
des documents similaires.
Doit-on identifier les résultats d’activités internes qui ne

sont pas transmises à d’autres processus ?
Non. Les contrats d'interfaces ont pour finalité d’améliorer les relations
entre les processus d’un organisme. Il ne faut pas les charger d’autres
missions et d’autres rôles sous peine d’alourdir et de complexifier l’orga-
nisation. Par exemple, dans un processus de livraison, le pilote organise
des séances de formation de ses chauffeurs. Il est le formateur. Le résultat
de cette activité n’est pas une donnée de sortie. Le résultat est une compé-
tence de ses chauffeurs. L’enregistrement de ces compétences sera forma-
lisé, soit dans le contrat d'interfaces (colonne «qui sait faire?»), soit dans
une matrice de compétences du processus en question. Dans ce cas, il serait
possible de considérer que la compétence nouvelle est malgré tout une
donnée de sortie. Mais s’il s’agit d’une remise à niveau, le résultat, dans ce
cas, n’en est pas une.
Est-ce important de définir et de préciser la finalité d’un

processus avant d’identifier ses données de sortie ?
Oui. La finalité est la raison d’être d’un processus. Il ne faut pas oublier
qu’un processus est un ensemble de ressources et que, à ce titre, un
processus est avant tout, aussi et en même temps, un centre de dépenses (ou
de coûts). Il est donc logique de déterminer sa mission, sa finalité afin de
savoir à quoi seront utilisés les fonds qui lui seront consacrés. La connais-
sance de la finalité est utile aussi pour évaluer les performances d’un
processus. Dans l’école privée dont j’ai parlé précédemment, le processus
de «développeur» n’existait pas. Il a été créé pour améliorer le fonctionne-
ment des unités pédagogiques en attribuant à une personne la responsabi-
lité d’un projet. Le besoin de résultats et la finalité ont été identifiés avant
la création du processus.
Qui est responsable ou pilote d’un processus qui travaille

en plusieurs équipes ?
Pour les travaux postés, il y aura un seul processus identifié bien entendu.
Mais il y aura (si cela est jugé nécessaire) un contrat d'interfaces par
équipe, chaque responsable d’équipe étant pilote du processus pour la
durée de son poste. Ces contrats pour chacune des équipes peuvent s’avérer
nécessaires si des consignes doivent être transmises par exemple d’un
poste à l’autre ou si des outillages doivent être préparés pour l’équipe qui
suit ou bien encore si des réglages ou des activités sont à cheval sur deux
ou trois équipes consécutives.
L’approche processus par la méthode de l’aval

peut-elle être utilisée pour la mise en œuvre
d’autres systèmes de management tel que
l’environnement ou la sécurité par exemple ?
Bien entendu. Dans ce cas, des données de sortie nouvelles apparaissent
qui sont directement identifiées par rapport aux référentiels concernés. Par
exemple, les rejets ou les consommations d’énergie seront identifiés
comme données de sortie dans chaque processus. Chaque responsable
devient donc comptable de ces données de sortie et aura à cœur de les
maîtriser et au besoin d’en réduire l’importance. Pour la sécurité, il est
possible de procéder de la même manière. Nous pouvons imaginer des
processus de management qui présentent les consignes, principes et règles
à appliquer pour réduire les risques liés à la sécurité des personnes et nous
pouvons imaginer des données de sortie comme par exemple « pièces
ébavurées» ou bien encore «rapport d’analyse de risque».
L’approche processus peut-elle s’appliquer en ingénierie

simultanée ?
Bien sûr. L’ingénierie simultanée met en présence dans une même zone (ce
qu’on appelle souvent un « plateau ») des représentants de plusieurs fonc-
tions travaillant sur un même projet (le plus souvent en R & D). Cela
permet une meilleure communication, les personnes étant proches les unes
des autres et cela réduit également les cycles de développement des
nouveaux produits. Le fait que les processus opèrent dans des territoires
communs ne nuit en rien à la mise en place d’une cartographie et de
contrats d'interfaces. Chaque processus sait ce qu’il doit fournir, ce que les
autres attendent de lui pour travailler efficacement et cette organisation
réduit fortement les délais de transmission des informations et améliore la
communication informelle. Toutes les informations qui passent d’un
processus à un autre ne peuvent être identifiées de manière exhaustive.
Nous identifions les plus importantes mais une foule de petites informa-
tions sont échangées chaque jour sans qu’elles figurent sur un document
quelconque. De plus, et ce n’est pas un des moindres avantages de ce type
d’organisation, les relations entre les personnes, de par un contact proche,
sont plus amicales et un esprit de groupe se forme plus facilement autour
d’un projet traité sur un plateau en ingénierie simultané.
Pourquoi faire simple…

Nous avons rencontré un jour des processus qui arborent fièrement à la fois
un pilote et un propriétaire. Le propriétaire s’occupe des revues de proces-
sus, il est responsable du bon fonctionnement du processus et de la perti-
nence des indicateurs. Le pilote, quant à lui, est responsable de la
performance du processus. Les processus sont bien entendu transversaux et
les ressources mises en œuvre ne sont ni sous la responsabilité du proprié-
taire ni sous celle du pilote. Elles dépendent des fonctions auxquelles elles
appartiennent hiérarchiquement.
L’approche processus a fourni beaucoup d’occupations à des cadres qui,
certainement, recherchaient un nouvel élan!
Un pilote peut-il justifier une mauvaise performance en

l’attribuant à une donnée d’entrée d’un fournisseur ?
Non, il convient de faire respecter la règle de la responsabilité en chaîne.
Chaque processus devient responsable de ses données d'entrée dès l’instant
où il en est l’utilisateur. Par exemple, un retard de livraison ne peut pas
s’expliquer par le retard de livraison du fournisseur. Chacun est respon-
sable de ses propres données de sortie et doit avoir le souci de la conformité
des données d'entrée qui leur correspondent. Si un fournisseur est en retard,
le client doit faire pression ou avoir le souci de ce retard et le prendre en
charge comme un problème à résoudre.

Questions Réponses Cartographie de Processus

Transféré par

Droits d'auteur :

Formats disponibles

Questions Réponses Cartographie de Processus

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Questions Réponses Cartographie de Processus

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 5 CHAPITRE 5

QUELQUES RÉPONSES CONCRÈTES

L’application de la méthodologie de cartographie par l’aval rencontre par-

QUESTIONS RELATIVES À L’IDENTIFICATION

Y a-t-il une méthode pour identifier les données de sortie

L’utilisateur d’une donnée de sortie

territoire. Ce processus est donc responsable des données de sortie de

Le rangement ou les résultats d’une activité de rangement

Les quantités de produits à fabriquer ou les délais de

Un transport de pièces est-il une donnée de sortie ?

Faut-il faire figurer dans les contrats d'interfaces les

genre de formulaires qui apparemment ne posent pas beaucoup de

Un indicateur est-il une donnée de sortie d’un processus ?

Comment formuler certaines données de sortie résultant

existe et constate l’état. Dans cette situation, la donnée de sortie est le

Une demande peut-elle constituer une donnée de sortie ?

Une procédure peut-elle être une donnée de sortie ?

Dans le second cas, la procédure est applicable dans plusieurs processus

Sous quelle forme se manifestent les données de sortie

Faut-il être précis dans la formulation des données

Comment identifier les données de sortie d’une activité

Des données de sortie temporaires doivent-elles figurer

formalisée sur les contrats d'interfaces. Il n’y a pas eu de problème de

Une attente d’un processus utilisateur peut-elle devenir

Combien de données de sortie un processus doit-il

Comment savoir exactement qui est client et qui est

nance de l’autre. Dans notre organisme, cette relation se simplifie à

Un dossier complet regroupant plusieurs documents

d’autres processus en fin de conception. Mais, il se trouve qu’un processus

QUESTIONS RELATIVES AUX ATTENTES

Doit-on faire figurer le client externe parmi les utilisateurs

Données de sortie Utilisateurs Attentes Habilitations, etc.

La colonne des attentes ne sera pas renseignée pour ce qui concerne le

Dans la colonne «attentes utilisateurs», doit-on faire

Peut-on refuser ou négocier les attentes des utilisateurs?

expliquant les économies ou l’intérêt qu’il trouvera si ses attentes sont

Les utilisateurs des données de sortie peuvent-ils être

Comment procéder quand les attentes d’un processus

Ce cas est fréquent et il constitue un des intérêts de la démarche par l’aval

Doit-on répondre obligatoirement à une attente

QUESTIONS RELATIVES À L’IDENTIFICATION

La direction d’un organisme constitue-t-elle un processus

Le processus qualité est-il un processus et dans quelle

processus de management disparaît au bénéfice de celui de la qualité. Il est

Une procédure peut-elle être confondue avec un

Quels processus peut-on classer dans la catégorie

Une activité comme l’intelligence économique

Un processus est-il toujours une fonction ou un service

à des services différents sont habilitées à vendre. Dans ce cas, il est

Le secrétariat est-il un processus ?

A quels processus attribuer des données de sortie issues

Y a-t-il un nombre de processus maximum à ne pas

Peut-on regrouper des processus pour en réduire le

Un processus externe (sous-traitant par exemple)

Est-il possible de procéder à la création d’un nouveau

Un processus peut-il être toujours client d’un autre

QUESTIONS RELATIVES AUX

Une procédure interne à un processus peut-elle demander

Seules les procédures générales considérées comme des règles de manage-