Faut-il du conseil dans un projet de mise en œuvre de 1C:ERP ?

À un certain stade de sa croissance et de son développement, une entreprise a besoin de méthodologies claires pour ses processus métier. Par exemple, pour prendre des décisions rapides et justes, un directeur général doit mettre en place une comptabilité de gestion : structurer le processus, construire un système de postes, définir les responsabilités, etc. Cela peut se faire en interne, mais expérimenter en y perdant du temps et de l’argent n’a pas de sens – après quelques essais de ce genre, l’entreprise risque de devoir fermer. L’entreprise n’a généralement pas de spécialiste adapté dans ses effectifs. Il est plus efficace de s’adresser à des professionnels qui réussiront du premier coup.

Les cabinets de conseil élaborent des politiques, par exemple une politique comptable ou une méthodologie de budgétisation – autrement dit, la manière dont l’entreprise doit fonctionner. Les intégrateurs de systèmes doivent ensuite transposer ces politiques dans le logiciel déjà en place ou en cours de mise en œuvre.

Cette approche présente un inconvénient majeur : les cabinets de conseil ne connaissent pas le système dans lequel les méthodologies qu’ils élaborent seront automatisées. Un système informatique intègre souvent déjà un cadre pour l’architecture des processus métier.

Par exemple, une entreprise utilise 1C:ERP Enterprise Management, et un cabinet de conseil distinct peut élaborer une méthodologie tout simplement impossible à mettre en œuvre dans ce système informatique. Il faut alors réécrire le logiciel existant et l’adapter par des développements spécifiques. On peut y investir 1 milliard de RUB (≈ 10 millions USD), et peut-être que dans 10 ans quelque chose en sortira – ou peut-être pas.

L’option idéale est celle où l’intégrateur de systèmes et le client élaborent ensemble la méthodologie et les modules de 1C:ERP. La méthodologie peut ainsi s’appuyer sur ce qui existe réellement.

Vous avez certainement besoin de conseil si :

- vous n’avez pas de méthodologie pour les processus métier de l’entreprise

- vous n’avez pas de politiques comptables pour chaque service

- tout est dans la tête des collaborateurs plutôt que « sur papier »

Nous fournissons ce type de conseil dans le cadre d’une automatisation globale clé en main.

Nous concevons l’architecture métier, construisons des modèles de processus et, dans la mesure du possible, ajustons les processus flexibles afin d’optimiser au maximum les processus métier, en limitant les développements spécifiques à ce qui est réellement nécessaire. Car chaque développement spécifique représente des millions dépensés en développement, en mises à jour et en support du système.

Sur nos projets, 70 % du travail est réalisé par des analystes et des architectes fonctionnels. Cette phase est la plus difficile et la plus longue. Voici comment cela se passe :

Nous étudions en détail les documents sources de l’entreprise

Nous examinons tous les processus métier. Des processus « cachés » apparaissent souvent, que même le propriétaire de l’entreprise ne soupçonnait pas

Nous établissons un registre de tous les processus de l’entreprise en documentant leur fonctionnement actuel chez le client, sans référence à l’ERP ni à aucun autre système. Cela ressemble par exemple à ceci

Diagramme eEPC du processus métier 1.02 « Assemblage (composition) des immobilisations »

Diagramme eEPC du processus métier 1.03 « Mise en service des immobilisations et des actifs incorporels / R&D »

À la phase de modélisation, nous réunissons deux visions : l’existant (as-is) et la cible (to-be)

Cette phase n’est pas non plus facile à accepter pour le client. Après la démonstration de la modélisation, les utilisateurs ne reconnaissent souvent tout simplement pas leur système ni leurs processus. Ils ont le sentiment que cela ne fonctionnera pas pour eux et qu’il leur faut un programme spécifique dans lequel tous les processus suivent l’ordre établi dans l’entreprise.

C’est compréhensible. Parfois, une entreprise doit « mourir et renaître ». C’est effrayant pour les collaborateurs, les managers comme pour le directeur général. Personne n’aime changer ses habitudes, encore moins payer pour cela. Mais en réalité, tout se résume à un choix : changer soi-même, ou payer des dizaines de fois plus et passer plusieurs années en développements spécifiques.

Pourquoi proposons-nous toujours les fonctionnalités standard de 1C:ERP ?

Parce que moins il y a de développements spécifiques, plus le budget du projet et les coûts de support, de mises à jour, etc. sont réduits. Et il s’agit de dizaines, voire de centaines de millions de roubles. Construire les bons processus s’avère donc plus rapide, moins cher et plus efficace.

« En général, les clients ne viennent pas nous voir pour du conseil. Ils ne comprennent pas vraiment pourquoi il est nécessaire ni quelle valeur il apporte. Ils ont simplement besoin d’un système de gestion d’entreprise moderne – idéalement rapide, pas trop cher et adapté à leurs processus.

C’est là que nous intervenons. Forts de notre connaissance des capacités de l’ERP et des spécificités sectorielles du client, nous concevons l’architecture des nouveaux processus et préparons les changements à opérer dans l’entreprise (quel collaborateur de quel service effectuera quelles actions dans le nouveau système) afin d’utiliser au maximum les fonctionnalités standard. Nous trouvons l’équilibre du triangle du projet : coût, qualité et délai. Montrer aux utilisateurs les résultats de la modélisation leur permet de comprendre clairement pourquoi les processus du nouveau système sont conçus ainsi.

Nos analystes sont des méta-spécialistes : non seulement ils connaissent à fond le logiciel mis en œuvre, mais ils sont aussi des experts de niveau consultant en processus métier. Un bon spécialiste de notre équipe connaît généralement deux ou trois modules de 1C:ERP (par exemple, Production, Entrepôt et IFRS de 1C:ERP), à la fois comme analyste métier et comme analyste système. Les grands projets exigent plusieurs analystes et architectes fonctionnels. »

Anton Kulish, directeur général de Tsifrovizatsiya Proizvodstva LLC (CIFP)

Le conseil, phase clé d’un projet d’automatisation 1C:ERP

Imaginez qu’un client s’adresse à un intégrateur pour automatiser sa production.

Un intégrateur expérimenté demande d’abord si l’entreprise dispose d’une méthodologie comptable documentée. Non ? Alors il faut commencer par là.

Il faut construire les chaînes d’actions qui doivent se dérouler en production :

• comment les processus doivent être reflétés dans le système,
• comment ils doivent être comptabilisés,
• comment le coût de revient sera calculé dans 1C:ERP,
• comment les coûts seront répartis, et ainsi de suite, pour chaque processus.

Ce système existe parfois dans la tête des collaborateurs. Parfois, il n’existe même pas là. « Automatiser la production » est compris ainsi : l’intégrateur doit élaborer la méthodologie. Le client suppose qu’elle est intégrée au système : « Vous automatisez, alors découvrez comment nous sommes organisés et dites-nous comment il faut faire. »

L’intégrateur doit donc rédiger la méthodologie. Par exemple, une politique comptable comporte une section sur la comptabilisation des immobilisations : elles peuvent être amorties de façon linéaire ou dégressive. Et le client doit en choisir une précisément. Et ainsi de suite pour chaque processus.

Les vêtements de travail, par exemple, peuvent être passés en charges intégralement et immédiatement, ou par fractions. On peut étaler la charge sur 10 ans pour un casque ultra-résistant qui dure de nombreuses années. Tout passer en charges d’un coup provoque un trop grand saut du coût de revient, qui devient inexact et irrégulier. Mais les gants, utilisés pendant une semaine, peuvent être passés en charges immédiatement. Plusieurs options sont donc possibles.

Comment automatiser la budgétisation ? Impossible sans méthodologie. Il faut des rapports avec des formules, et le processus de budgétisation doit être documenté : comment les budgets sont approuvés, ajustés et planifiés.

Le conseil doit donc répondre précisément à la question de savoir comment ces processus doivent se dérouler et fixer des procédures pour eux.

Le rôle de l’intégrateur est d’automatiser ces processus dans la solution choisie – schématiquement, de « cocher les cases » là où il le faut.

Les intégrateurs expérimentés abordent un projet de manière globale (ce que nous appelons le « clé en main »). Dans ces projets, la phase d’analyse des processus métier vient en premier. L’intégrateur étudie les processus existants, leurs interconnexions, les goulots d’étranglement, etc. Plus l’analyse est approfondie et détaillée, plus le client obtient un calendrier et un coût de projet précis. Mieux vaut ne pas se précipiter ici.

À partir des données recueillies, l’intégrateur engage son travail de conseil, qui aide à rationaliser les processus et à économiser des sommes importantes.

Bien sûr, on peut se passer de conseil. Cela fait gagner du temps et, à première vue, de l’argent. La plupart des intégrateurs font exactement cela. C’est pourquoi on voit souvent des projets dont les résultats ne satisfont pas le client, ou des projets qui s’enlisent tout simplement.

Nous recommandons de ne pas courir après des délais courts et un prix initial bas. Mieux vaut examiner de près la façon de travailler de l’intégrateur, poser des questions et discuter des détails lors des réunions de lancement.

Pourquoi le conseil en interne n’est pas le meilleur choix

Les équipes externes mènent généralement les projets avec plus de succès, même si elles connaissent moins bien les processus de l’entreprise.

Pourquoi ?

La clé du succès d’un projet est un chef de projet qui connaît bien les processus métier de l’entreprise et travaille avec une équipe externe.

Une équipe externe a plusieurs atouts que les collaborateurs n’ont pas.

1. Un regard neuf sur les processus. Quand on est à l’intérieur, on ne peut pas être objectif. C’est simplement de la psychologie humaine.
2. Aucune contrainte personnelle. Il n’y a pas de relations étroites et affectives avec les collaborateurs. On peut ainsi dire calmement et franchement ce qui doit changer. Il s’agit parfois de sujets très sérieux, pouvant aller jusqu’à supprimer des postes ou envoyer des personnes en formation.
3. Un large horizon. Une équipe externe a l’expérience d’autres projets et sait comment sont organisées des entreprises performantes comparables.
4. Expertise. Les connaissances et l’expérience acquises en automatisant d’autres entreprises permettent d’éviter les pièges et de proposer une voie plus efficace et plus rapide.

Pourquoi un programmeur ne peut-il pas mettre en œuvre un ERP ?

Il arrive souvent qu’une entreprise achète une « boîte » (le logiciel lui-même), embauche un spécialiste 1C et tente de mettre en place 1C:ERP ainsi. Même de grandes entreprises commettent cette erreur. L’un de nos projets a démarré exactement de cette façon. Sur le site de production à la chaîne de l’une des plus grandes entreprises de construction, un programmeur a installé 1C:ERP Enterprise Management 2.5, mais n’a pas réussi à relier le système aux opérations réelles. Il lui manquait les connaissances d’un analyste et d’un architecte fonctionnel. Et ce volume de travail est de toute façon trop important pour une seule personne. Il a donc tout simplement démissionné du jour au lendemain.

Un programmeur peut rédiger un cahier des charges ; il connaît 1C:Enterprise 8.3 et, en particulier, 1C:ERP Construction Company Management, et il connaît le code. Que demander de plus ? Mais il ne connaît pas cette entreprise précise : ni les nuances de son activité, ni l’ensemble de ses processus métier. En fait, il n’est pas du tout nécessaire sur le projet pendant les six premiers mois.

La phase de mise en œuvre est précédée d’un important travail de conseil. Il s’agit d’étudier à fond l’entreprise et ses processus : analyser la situation réelle, modéliser le résultat souhaité, le valider avec les utilisateurs et modéliser les développements spécifiques si nécessaire. C’est seulement ensuite que le programmeur se met au travail.

Autrement dit, sans conseil en amont, le projet est voué à l’échec.

Notre conseil : ne sautez jamais les phases d’analyse des processus métier et de conseil. Plus les analystes et les architectes sont experts, meilleur, plus rapide et moins cher sera le projet.