L’approche processus dans le contexte d’un progiciel intégré

Modéliser ses processus avant de choisir son outil

Ce devrait être une évidence et pourtant combien d’entreprises prennent le temps de remettre à plat leur processus cibles avant de choisir leur progiciel intégré ?

Décision de la maison mère ou volonté de passer rapidement aux choses sérieuses (l’appel d’offres), le choix de l’outil précède trop souvent les analyses organisationnelles quand il ne les court-circuite pas purement et simplement.

Rien de bien grave me direz-vous : l’ERP étant « structurant », à quoi cela sert-il de définir ses besoins dès lors que l’on devra faire ensuite avec les possibilités (et les limites) de l’outil. Certes, le choix de l’ERP est structurant… d’autant plus qu’il est déjà choisi !

Or sur quoi va désormais reposer le choix de l’outil si l’on ne peut soumettre son adaptabilité supposée au tamis très fin des besoins utilisateurs ? Sur les contraintes budgétaires, la notoriété des fournisseurs et… la qualité des présentations commerciales.

Faisons confiance aux équipes d’avant vente, avant de signer, tout est toujours possible et les difficultés supposées « transparentes », réponse d’autant moins critiquable que la question est souvent peu précise. Au bout du compte, le constat est toujours le même : les difficultés de mise en œuvre sont toujours liées à des « détails » dont certains peuvent être fondamentaux pour l’entreprise; d’où des surcoûts ou des frustations au niveau des utilisateurs qui entâchent l’image du nouveau produit et de l’équipe projet, quand bien même les apports fonctionnels seraient très significatifs par ailleurs.

Une fois prise en compte le temps passé au traitement de ces oublis fonctionnels, le calcul a posteriori est en général sans appel : une modélisation préalable des processus de l’entreprise n’aurait généré ni retard ni surcoût, bien au contraire. Et l’entreprise aurait disposé d’un référentiel sur lequel elle pouvait s’appuyer pour entamer une démarche d’optimisation continue.

S’il ne faut pas attendre des éditeurs une réponse circonstanciée à un cahier des charges détaillé, l’existence de ce référentiel permettra au moins de cibler la demande sur les spécificités de votre organisation qui pourraient ne pas rentrer dans le cadre des « best practices » planétaires.

La modélisation sécurise la phase de mise en œuvre

C’est entendu, vous avez choisi l’outil avant de formaliser en détail vos beoins : il est encore temps d’introduire les processus dans la phase d’analyse fonctionnelle.
Certes, l’intégrateur choisi, une société pourtant renommée de la place, ne pousse pas forcément en ce sens : la méthode maison a fait ses preuves et le chef de projet la maîtrise parfaitement.
Mais l’éditeur vous facilite la tâche : la nouvelle version n’est-elle pas TOTALEMENT ORIENTEE PROCESSUS et ses processus ne sont ils pas déjà tous modélisés ? Vous gagnerez un temps précieux à vous appuyer dessus !

Vous avez raison de vous méfier! L’éditeur a modélisé SES processus, c’est à dire les diagrammes de traitement que vous pouvez adapter et enchaîner à votre guise. En dehors de vous renseigner sur le fonctionnement intime de l’outil (ce qui n’est pas sans intérêt), ces modèles ne peuvent se substituer aux processus métiers de l’entreprise. Ils n’intégrent ni votre organisation, ni les spécificités de votre activité, encore moins les interactions avec vos sous-traitants ou partenaires. Bref, on ne parle pas des mêmes choses.

La modélisation des traitements informatiques n’est pas – à ce stade – d’un grand secours ; elle peut même fausser l’analyse des besoins si elle l’influence trop : c’est une fois les processus métiers décrits – en faisant abstraction de l’outil – que l’on pourra s’attacher à les rapprocher des processus « outil » et se poser la question du traitement des écarts fonctionnels : adaptation de l’organisation au fonctionnement standard ou adaptation de l’outil à l’organisation.

L’ERP mis en place, place à l’information décisionnelle

La mise en place du progiciel intégré avait souvent pour première ambition d’améliorer le suivi financier en facilitant les analyses transversales au sein de l’entreprise. Celle de modules ou d’applications complémentaires (CRM, logistique, décisionnel,…) a permis de fournir de multiples analyses, essentiellement orientées marché : par client, par canal de distribution, par produit,…

Sans oublier les démarches d’Activity Based Costing qui poussent très loin les logiques de ventilation des coûts indirects pour obtenir des coûts complets par processus et par produit.

Une fois cette photographie obtenue se pose la question de l’amélioration de la performance : comment optimiser ces processus dont on a désormais une vision très précise ?
Les logiciels d’optimisation existent certes mais leur apport dépend beaucoup des données qui les alimentent. Et quand celles-ci sont disponibles au bon niveau de détail, encore faut-il choisir une période de référence qui soit réellement représentative.
C’est l’objet des logiciels de B.A.M. (Business Activity Monitoring) de fournir en permanence ces données de contrôle.

Et maintenant le pilotage de la performance opérationnelle.

Le paradoxe du pilotage de la performance opérationnelle est que l’entreprise dispose de beaucoup d’éléments pour la mesurer mais que ces éléments sont trop dispersés pour que leur traitement soit simple sans le logiciel ad hoc.

En effet, le système d’information de l’entreprise donne des photographies parcellaires de processus à un instant donné : telle commande possède tel statut à tel moment. Et la structure des données, en dépit des discours marketing, reste orientée « traitement ».
Pour retracer le film du déroulement de cette commande dans son ensemble, il s’agit de multiplier ces photographies et de les relier entre elles. On obtient alors une vue objective de l’évolution dans le temps d’une instance de processus. Il devient alors aisé de suivre sa performance opérationnelle, quasiment en temps réel.

C’est l’objet de ces outils de B.A.M. de transformer les données disponibles en analyses multi dimensionnelles de la performance opérationnelle : délai de traitement de chaque processus, taux d’erreur, volumes en attente… Un secteur qui devrait décoller dans les mois à venir et des outils qui, en tirant pleinement partie des données de disponibles, permettront d’augmenter sensiblement le retour sur investissement du projet ERP.

L’approche processus dans le contexte d’un progiciel intégré