A qui appartiennent les [modèles de] Processus ?
Question saugrenue ou véritable problème organisationnel ?
Tout d'abord, à qui appartiennent les Processus ?
Hypothèse : les processus appartiennent aux métiers.
Les processus appartiennent aux métiers, donc à ceux qui les vivent. Cela semble vrai et efficace : le propriétaire, le gestionnaire, l'administrateur, le pilote, le référent, (etc.) du processus est un acteur métier. Cependant c'est une information presque inutile, puisque le processus ne peut être manipulé, modifié, amélioré, étudié, (etc.) que s'il est modélisé.
A qui donc appartiennent ces modèles de processus ?
C'est une question qui existe dans toutes les organisations, et qui renvoie l'image de la difficulté qu'on a à opérer de façon transverse. Si le processus est transverse, la gestion du modèle l'est , elle, parfois un peu moins.
Les métiers de qualiticien, de stratège, de pilote opérationnel, d'exploitant ou d'architecte SI utilisent tous des modèles de processus. On est même parfois confronté à des modèles différents en fonction de ces métiers, voire de l'usage qui est fait du processus.
Si l'on décrète que la Qualité est propriétaire des modèles de processus, comment garantir que l'architecte SI, sans avoir le droit de redessiner le processus, pourra faire son travail ?
Si le métier possède les modèles de processus on va tomber dans le même travers : une représentation unique destinée à piloter l'activité, mais pas à destination des entités support.
La solution passe par la tolérance
Cinq minutes de tolérance. Vous passez devant un bureau et surprenez un dissident en train de modéliser un processus sans mandat officiel...
Votre réaction ? Virez-le !
Non, essayez de comprendre ses raisons : on n'a jamais tort de redessiner un processus dans son coin, on aurait juste tort de croire qu'il fait foi.
La solution passe aussi par la collaboration
L'étape suivante est la collaboration dans la modélisation de processus : ne gardez pas votre savoir enfermé en lecture seule dans votre référentiel de processus (ou dans ce qui fait office de référentiel). Si une équipe, ailleurs dans l'entreprise, apporte sa modeste pierre à l'édifice, acceptez-là comme un enrichissement.
Il y a autant de modèles de processus qu'il y a de métiers qui les utilisent, et votre référentiel, si bien constitué qu'il soit, ne pourra donc pas tous les contenir.
Définir le langage métier de l'entreprise
L'important au fond est de savoir de quoi on parle, et de fixer au minimum le vocabulaire métier. Pour cela le référentiel devra contenir les listes de termes décrivant vos processus : si "acquisition client" est le nom d'un processus, vous devrez expliquer pourquoi ce nom devrait remplacer, si possible, les autres (tels que "vente", "acquérir client", etc.), afin de vérifier qu'on parle de la même chose. Vous définirez aussi "client", vous direz qu'est-ce qui caractérise une "acquisition", et si d'autres objets métier sont importants pour ce processus. Vous trouverez grand nombre des objets métier importants dans les indicateurs de performance du processus (définis conjointement par la Direction, la stratégie et les acteurs du processus). Vous devrez ensuite accepter modestement que dans votre référentiel le modèle de ce processus, représenté par un diagramme, n'est qu'une illustration.
Propriété collective
Les modèles de processus appartiennent à ceux qui les utilisent, ils peuvent varier d'une entité à une autre. Ils doivent respecter le langage métier de l'entreprise, ou expliquer pourquoi ils divergent de ce langage, si c'est leur finalité (dans le cas d'une conduite de changement par exemple).
Et surtout, restez modeste : les modèles de processus sont toujours un peu faux.
Question saugrenue ou véritable problème organisationnel ?
Tout d'abord, à qui appartiennent les Processus ?
Hypothèse : les processus appartiennent aux métiers.
Les processus appartiennent aux métiers, donc à ceux qui les vivent. Cela semble vrai et efficace : le propriétaire, le gestionnaire, l'administrateur, le pilote, le référent, (etc.) du processus est un acteur métier. Cependant c'est une information presque inutile, puisque le processus ne peut être manipulé, modifié, amélioré, étudié, (etc.) que s'il est modélisé.
A qui donc appartiennent ces modèles de processus ?
C'est une question qui existe dans toutes les organisations, et qui renvoie l'image de la difficulté qu'on a à opérer de façon transverse. Si le processus est transverse, la gestion du modèle l'est , elle, parfois un peu moins.
Les métiers de qualiticien, de stratège, de pilote opérationnel, d'exploitant ou d'architecte SI utilisent tous des modèles de processus. On est même parfois confronté à des modèles différents en fonction de ces métiers, voire de l'usage qui est fait du processus.
Si l'on décrète que la Qualité est propriétaire des modèles de processus, comment garantir que l'architecte SI, sans avoir le droit de redessiner le processus, pourra faire son travail ?
Si le métier possède les modèles de processus on va tomber dans le même travers : une représentation unique destinée à piloter l'activité, mais pas à destination des entités support.
La solution passe par la tolérance
Cinq minutes de tolérance. Vous passez devant un bureau et surprenez un dissident en train de modéliser un processus sans mandat officiel...
Votre réaction ? Virez-le !
Non, essayez de comprendre ses raisons : on n'a jamais tort de redessiner un processus dans son coin, on aurait juste tort de croire qu'il fait foi.
La solution passe aussi par la collaboration
L'étape suivante est la collaboration dans la modélisation de processus : ne gardez pas votre savoir enfermé en lecture seule dans votre référentiel de processus (ou dans ce qui fait office de référentiel). Si une équipe, ailleurs dans l'entreprise, apporte sa modeste pierre à l'édifice, acceptez-là comme un enrichissement.
Il y a autant de modèles de processus qu'il y a de métiers qui les utilisent, et votre référentiel, si bien constitué qu'il soit, ne pourra donc pas tous les contenir.
Définir le langage métier de l'entreprise
L'important au fond est de savoir de quoi on parle, et de fixer au minimum le vocabulaire métier. Pour cela le référentiel devra contenir les listes de termes décrivant vos processus : si "acquisition client" est le nom d'un processus, vous devrez expliquer pourquoi ce nom devrait remplacer, si possible, les autres (tels que "vente", "acquérir client", etc.), afin de vérifier qu'on parle de la même chose. Vous définirez aussi "client", vous direz qu'est-ce qui caractérise une "acquisition", et si d'autres objets métier sont importants pour ce processus. Vous trouverez grand nombre des objets métier importants dans les indicateurs de performance du processus (définis conjointement par la Direction, la stratégie et les acteurs du processus). Vous devrez ensuite accepter modestement que dans votre référentiel le modèle de ce processus, représenté par un diagramme, n'est qu'une illustration.
Propriété collective
Les modèles de processus appartiennent à ceux qui les utilisent, ils peuvent varier d'une entité à une autre. Ils doivent respecter le langage métier de l'entreprise, ou expliquer pourquoi ils divergent de ce langage, si c'est leur finalité (dans le cas d'une conduite de changement par exemple).
Et surtout, restez modeste : les modèles de processus sont toujours un peu faux.
