Le système doit aider l'entreprise à progresser,
il doit
protéger l'entreprise. Il ne doit pas être
pensé
pour répondre à une norme (ISO ou autre), sinon
cela
devient lourd, rejeté par les
salariés, et sans gain
à long terme pour l'entreprise.
Parfois cela peut-être un argument commercial mais, si ce
n'est
que cela, c'est un calcul à court terme (très
occidental).
Le système est là pour protéger
l'entreprise dans son domaine d'activité et dans son
environnement.
Une application
juste pour répondre à la norme et sans prise de
recul donne les choses suivantes :
- trop de procédures (hors elles sont là pour
capitaliser, comme aide mémoire)
- perte de visibilité, de compréhension
- rejet du concept (si n'apporte rien, pas de gain visible)
- trop d'enregistrements (à quoi servent-ils, que peut-il
m'arriver si je ne le fait pas, est-ce du 100% ou du
fréquentiel
?...)
- introduction d'immobilité (cela donne des standards qui
doivent être appliqués, car sans standard, il n'y
a pas
d'amélioration possible mais, ils faut faire
évoluer en
fonction des améliorations apportées)
- trop de lourdeurs (il ne faut pas, dans tous les domaines, chercher
à couvrir tous les cas possibles et inimaginables. traiter
les
80 ou 90% et le reste est traité par dérogation)
- documents illisibles car trop long (préférer
ajouter
des check list que de tout décrire dans une
procédure)
Pourquoi en
arrive-t-on à ce niveau ?
- manque de prise de hauteur
- incapacité de penser "simple" (le B.S.P. = bon sens
paysan)
- mauvaise connaissance du sytème et de ses objectifs
* interprétation non pertinente des
textes
- manque de formation à l'écriture des
procédures
* trop de détails
* incapacité de dicerner
l'indispensable du détail
* pas de règle d'écriture
des procédures
* volonté de se protéger
contre tous les risques possibles et inimaginables
- écriture unilatérale sans faire participer les
acteurs (comment les faire agir ensuite ?)
- manque d'écoute des utilisateurs (quel est le clent ?,
cela
répondit bien à la problématique de
l'entreprise ?)
Les procédures sont la traduction littérale du
comment
réaliser une tâche "complexe" qui concerne
plusieurs
services. Elles doivent être écrites avec des
représentants (mandatés par les
hiérarchiques pour
qu'il n'y ait pas de discussion ensuite sur la validité de
la
procédure) de chaque service concerné. Car si
chacun
écrit une procédure qui concerne son service de
son
côté, le tout sera totalement
incohérent (l'effet
tour de Babel).
Ecriture d'une
procédure :
Il ne sert à rien d'écrire à rien
d'écrire
qu'il faut appuyer sur la pédale de frein (pédale
du
milieu) pour freiner (sauf aux Etats Unis bien sûr)
par
contre il peut être utile d'écrire qu'il faut
faire
réviser l'état des freins tous les 15.000 km et
vérifier l'état de ses pneus avant chaque
départ.
A
ne pas faire :
Croire qu'une procédure sert à remplacer toute
personne
absente (cela peut se gérer en partie par des modes
opératoires = décriptif d'une tâche
d'une
personne). En faisant cela, l'on rentre dans une multitudes de
détails inutiles qui alourdissent la procédure et
qui
fait qu'elle n'est jamais lue.
Il ne faut pas oublier que la plupart des choses sont apprises au
travers d'une longue expérience qu'un simple
document ne
peut pas remplacer.
Elle ne doit pas pallier à des incompétences
(cela est du ressort de la formation et du recrutement en aval)
Comment
alléger le système :
disposer de personnel formé et qualifié. Cela
veut dire
avoir un mode de formation efficace (en s'assurant qu'au moins 2
personnes possèdent la connaissance)
A
faire :
Même si une procédure ne peut pas remplacer
l'expérience, complétée
par des check-list, elle doit essayer de traduire cette longue
expérience. Se sont les standards de la
société
(comme les gammes en production). Et, comme les gammes elle doivent
être respectées car sinon quand vous voulez
améliorer le système vous ne savez sur quel point
agir
car vous ne savez ce qui est fait en réalité.
Elles doivent être courtes (3 à 4 pages au plus)
Préférer les logigrammes que les longs textes
Ecrire ce qui est important ou ce qui peut être
oublié
Faire une analyse des risques pour savoir où
écrire une
procédure (cela peut être basé sur
l'expérience)
Si le risque n'exite pas = pas de procédure
si le risque est minime = se contenter de quelques lignes
si le risque est grand = bien penser la procédure, la tester
avant de la valider
A
quoi servent-elles :
Capitalisation des meilleures façons de procéder
Support de formation pour les nouveaux arrivants (leur permet d'avoir
une vision sur le mode de fonctionnement et sur la culture de
l'entreprise)
Ne jamais oublier :
Les procédures ne doivent pas être source de non
performance.
le but viser est la satisfaction du client (interne ou externe; cela ne
veut pas dire oui à tout sans mise en garde ou
contre-partie).
Nous travaillons pour nous, pour faire progresser notre
société, non pas pour satisfaire l'ISO .
Bref si les gens rejettent le système, c'est qu'il n'est pas
adapté aux besoins
