Les moteurs de workflow actuels permettent de coder toutes les règles que vous pouvez imaginer, et ce d'autant plus "facilement" que vous disposez d'un référentiel d'entreprise ou autre annuaire LDAP. Vous pourrez, par exemple, automatiser la consultation de l'expert sécurité pour autoriser la commande d'un mobilier de bureau hors catalogue dans un immeuble de grande hauteur. Cela, c'était la bonne nouvelle, voici la mauvaise, vous pourrez automatiser toutes les règles que vous pouvez imaginer ! A la différence des progiciels ERP qui étaient livrés avec une bibliothèque de "bonnes pratiques", les progiciels d'eApprovisionnement sont des boîtes à outils. Il va donc vous falloir concevoir vos propres "bonnes pratiques". Cet éditorial propose, sous le registre "ne pas faire/faire", quelques "règles du pouce".

Limiter à sa plus simple expression l'analyse de l'existant. Quand on met en place un ERP, c'est généralement, la deuxième ou la troisième fois que la comptabilité ou la gestion de production est automatisée. Dans ce contexte, l'expression de besoin est naturellement "faites-moi la même chose que la fois d'avant, avec ceci en plus et cela en moins ". C'est donc une conception "à la marge", par incrément/avenants à l'existant. Il est donc naturel d'analyser l'existant et d'identifier les points d'amélioration. Quand on met en place un eApprovisionnement, c'est la première fois qu'on automatise le domaine. La philosophie et les pratiques d'un système manuel et "coutumier" sont très différents d'un système automatisé et procéduré.

Ne pas partir de ce que propose, en standard, le progiciel. En effet, le niveau actuel du standard des progiciels d'eApprovisionnement est trop limité pour être une réponse acceptable à tous les cas de figures. Certes, tous les progiciels savent gérer l'auto-validation d'achats de gommes et crayons et l'approbation par le N+1 au-delà d'un seuil, mais il n'y a pas que des gommes et des crayons à acheter et le N+1 n'est pas toujours le bon approbateur.

Limiter l'expression de besoins. D'abord, il n'existe généralement pas de pratique homogène et systématique. De plus, la progression d'un parapheur suit des règles systémiques très différentes de celle d'un workflow. Ainsi, chaque intervenant est susceptible, d'une part, de corriger et d'enrichir une demande d'achats et, d'autre part, de réorienter le parapheur. Imaginons une demande d'achat (DA) informatique hors catalogue d'un montant de 90. Le montant de cette DA est inférieur au seuil de 100, le demandeur ne la transmet donc pas au contrôleur de gestion mais à l'expert informatique. L'expert informatique complète la DA et met à jour le prix à 110. Le seuil de 100 étant maintenant dépassé, l'expert informatique réoriente la DA vers le contrôleur de gestion. Il y a décidément beaucoup d'intelligence dans les systèmes à base de parapheurs !

Ne pas chercher à tout contrôler à la saisie de la demande d'achat. Soyons bien conscients que nous sommes tous conditionnés par la philosophie d'approche des systèmes transactionnels des années 70-80 dont l'ERP est l'ultime avatar. Dans un système transactionnel, tout doit être contrôlé à l'entrée, contrôle par rapport à des listes de champs possibles, contrôle inter zone etc. En effet, dans un système transactionnel, tout se joue à la saisie ; il n'y a plus de gestion des rejets comme dans la génération antérieure des systèmes batchs et il n'y a pas, encore, comme dans l'eApprovisionnement, de workflow ultérieur d'approbation. La philosophie de saisie de l'eApprovisionnement est différente : la saisie par le demandeur est suivie, complétée et enrichie par un workflow d'approbation où différents experts viendront corriger la demande initiale.

Ne pas hésiter à utiliser les procédures manuelles. Il est particulièrement stimulant pour l'esprit de conceptualiser et automatiser tous les cas de figures. Il faut cependant bien garder en mémoire le coût de maintenance d'une telle approche. Reprenons l'exemple de notre expert sécurité d'immeuble de grande hauteur, lors du pilote, nous avions retenu une approche automatique d'identification … que nous avons abandonnée au profit d'une approche manuelle lors du déploiement. De la même manière, dans un groupe international, après avoir conceptualisé un gigantesque annuaire d'entreprise, nous avons finalement adopté le principe que "nul n'est censé ignorer la loi".

Adopter un schéma général de workflow à trois niveaux : le demandeur, les valideurs et l'ayant bon pouvoir. Le demandeur n'est pas "monsieur tout le monde", c'est un initié, un approvisionneur au sens noble du terme, cela peut être l'assistante du département pour les fournitures de bureau ou la logistique pour le mobilier. L'ayant bon pouvoir est la personne autorisée, au sens mandataire social, pour engager l'entreprise sur la section budgétaire. Attention, il peut ne pas être un hiérarchique du demandeur. Contrairement à la vulgate américaine, ce n'est pas toujours le "chef", le "N+1" qui approuve la demande d'achat. Il peut y avoir autant de valideurs que l'on souhaite. Il suffit d'expliciter les conditions d'identification et d'intervention du valideur. Lorsque ces conditions sont difficiles à expliciter, rien n'empêche de rajouter manuellement un valideur. Tous les valideurs sont en parallèle, c'est plus simple et ça marche ! Règle importante, les valideurs ne corrigent pas la DA, ils les retournent au demandeur. Ainsi, dans l'exemple précédent de la DA hors catalogue informatique d'un montant de 90, l'expert informatique retourne au demandeur sa DA en lui donnant la bonne spécification et le bon prix, à savoir 110. Le demandeur va compléter sa DA et la re-soumettre. Elle sera, cette fois, routée au contrôleur de gestion puisque le montant est supérieur à 100.