Combiner les systèmes comptables d'une succursale éloignée et leur intégration avec la structure mère est une tâche assez difficile, même en Russie. Et lorsque le client est à l'étranger, l'ensemble du projet peut compliquer le manque d'expertise dans les lois fiscales locales et les conflits de mentalité. Je m'appelle Stanislav Gotz, je suis le chef du département de développement des systèmes ERP Lamoda et dans ce post, je vais vous parler de cette expérience - de la mise en œuvre d'un système ERP dans notre branche allemande.
Notre filiale allemande achète des marchandises et les vend à une entité juridique russe. Le système Tsenit utilisé ne permettait de tenir des registres qu'au niveau des données financières: qui, qui et combien d'argent dû, quand l'achat ou la vente a eu lieu, etc. Il était impossible d'effectuer la comptabilité des marchandises et des tâches logistiques à l'aide des outils Tsenit; pour résoudre ces problèmes, des outils supplémentaires devaient être utilisés, ce qui affectait négativement la vitesse et la fiabilité de l'ensemble du système. En conséquence, les données ont été dispersées dans plusieurs bases de données.
En outre, l'entité juridique allemande doit soumettre des rapports, payer des impôts et passer des audits - et avec les systèmes comptables existants, il n'a pas été facile de résoudre de tels problèmes.
Pour comprendre pourquoi telle ou telle transaction financière a été effectuée à Tsenit et répondre à des questions simples des autorités fiscales ou des auditeurs, j'ai dû pelleter manuellement d'énormes quantités de données dans Excel et contacter le service logistique.
À un moment donné, il a été décidé de combiner la comptabilité et les finances avec la logistique en un seul circuit dans le cadre d'un système ERP à succursale unique. Comme le logiciel principal a été choisi Microsoft Dynamics 365 - ancien Dynamics AX, ou encore plus simple - Axapta. Il n'y a presque pas de clients russes utilisant la solution cloud de ce système (pour être plus précis, nous sommes devenus le deuxième), mais elle était la mieux adaptée à nos besoins.
Calendrier, budget et croyance dans un avenir radieux
Nous avions des délais stricts: le lancement d'un tel système au milieu d'un exercice exigeait le transfert de l'ensemble des données historiques, ce qui serait une tâche impossible, car dans l'ancien système, la comptabilité des marchandises était pratiquement absente et conservée dans des feuilles de calcul. Mais au début de la période considérée, il suffit de ne transférer que les soldes. Il a donc fallu le lancer soit le 1er janvier 2019, soit le reporter d'une année supplémentaire. Les processus associés à la logistique du commerce et des entrepôts ne sont pas particulièrement complexes et il nous a semblé qu'il n'y aurait pas de problèmes de délais.
En plus des délais, il y avait aussi un problème de budget: déployer et maintenir votre propre infrastructure informatique en Allemagne et acheter des licences de logiciels d'entreprise est trop cher par utilisateur.
Puisque pas plus de 20 personnes participent aux processus commerciaux allemands, nous avons opté pour la solution cloud Dynamics 365. Pour les petites succursales distantes, le schéma SaaS est optimal, il vous permet d'obtenir tous les logiciels et environnements de développement nécessaires pour commencer la mise en œuvre immédiatement après la signature du contrat avec le fournisseur.
La politique de licence de Microsoft Dynamics 365 est extrêmement simple et suppose un prix fixe pour une licence utilisateur par mois, tandis que le nombre d'utilisateurs peut être augmenté ou diminué. C'était un autre argument pour choisir ce produit logiciel particulier.
Pièges
Le principal problème se situe en dehors du plan technique: nous ne connaissions pas toutes les exigences de la législation européenne pour la tenue de registres dans ces systèmes. Microsoft Dynamics 365 couvre un grand nombre de processus métier; de soi-disant packages de localisation sont publiés qui vous permettent de personnaliser de manière flexible la solution aux spécificités de la législation d'un pays particulier. Si l'équipe de développement a étudié la version russe pendant longtemps, nous n'avons jamais rencontré de version pour l'Allemagne. La mise en place d'une telle solution par votre propre équipe serait une tâche difficile.
La direction allemande craignait que la partie russe ne puisse pas faire face à la tâche en raison du manque d'expérience et de connaissances en matière de fiscalité et de comptabilité locales. En conséquence, nous avons choisi le terrain d'entente et attiré des consultants externes. Il était censé combler les lacunes liées aux exigences légales européennes, fournir un audit de la migration du système financier précédent, analyser les descriptions des processus commerciaux, les optimiser et adapter la future solution avec l'utilisation maximale des fonctionnalités standard. Si nécessaire, ils devaient être achevés, plongeant progressivement l'équipe russe dans le développement.
Début de la mise en œuvre et du transfert de données
Par défaut, nous avons obtenu les droits sur trois environnements: BUILD - pour assembler le code créé par différents développeurs en une seule application, SAT (Standard Acceptance Testing) - pour effectuer des tests d'acceptation utilisateur, et PROD - pour le fonctionnement. De plus, des machines virtuelles dev-box sont déployées pour chaque développeur dans Azure. L'infrastructure entière est gérée et surveillée via un portail unique - les services du cycle de vie , et une caractéristique du processus de personnalisation est que toutes les améliorations n'entrent dans l'environnement PROD que via le SAT.
Étant donné que Microsoft Dynamics 365 a été choisi comme nouveau système, le transfert de données a été relativement facile à mettre en œuvre à l'aide des packages de données disponibles dans la boîte. Dynamics 365 a une relation étroite avec les produits Microsoft, y compris Excel: pour l'utilisateur, il ressemblait à une feuille de calcul connectée aux services Dynamics 365 via
ODATA . À l'aide de l'extension Excel, les utilisateurs ont publié des données directement sur le système. La partie allemande a préparé les modèles, en notant les colonnes requises. Les utilisateurs ont rempli ces modèles et les consultants ont contrôlé le processus d'importation.
Entre autres choses, de l'ancien système comptable, les consultants ont transféré des informations sur les fournisseurs et les clients, ainsi que les soldes des comptes du grand livre. Le transfert direct de toutes les données sur les marchandises nécessiterait beaucoup de temps et d'efforts, et nous avons essayé de résoudre ce problème de manière plus efficace. L'intégration du nouveau système comptable de la succursale allemande avec le principal système russe, dans lequel se trouvent les données de base sur les marchandises, a été mise en œuvre. À la fin de l'année, nous n'avions pas de soldes physiques en Allemagne et, par conséquent, il était nécessaire de transférer de l'ancien système uniquement les informations de base nécessaires à la poursuite de la distribution des marchandises. Ainsi, il a été possible de se passer du transfert de toutes les données historiques sur les marchandises, ce qui a permis de gagner du temps.
Semi-externalisation: connecter l'équipe russe
Après avoir commencé la mise en œuvre en juin 2018, nous nous attendions à résoudre tous les problèmes avant les vacances du Nouvel An, mais en plus des problèmes de langage naturel dans de tels projets, des difficultés de communication sont apparues. Les consultants allemands répondent depuis longtemps aux demandes de renseignements. Un employé ne peut pas travailler sans pause pendant plus de 6 heures consécutives. Après avoir terminé son travail, il doit avoir un minimum de 11 heures de temps libre. Et lorsqu'un spécialiste traite avec un autre client, on ne peut lui demander quoi que ce soit. Une telle approche formelle a affecté le calendrier. À un moment donné, l'entrepreneur a proposé par la nouvelle année de lancer uniquement la comptabilité financière, qui fonctionnait déjà dans l'ancien système. Cela ne nous convenait pas. Depuis 2013, nous mettons en œuvre Axapta de manière indépendante à Lamoda, et en 2016, nous avons complètement transféré toute la comptabilité de 1C à celle-ci. Les processus en Russie sont beaucoup plus complexes, nous savions donc que le projet pourrait être achevé à temps.
Nous avons décidé d'attirer l'équipe russe, en prenant à nos collègues d'Allemagne toute la personnalisation et le développement de la fonctionnalité du système. En fait, nous avons laissé à l'entrepreneur externe uniquement le conseil, la définition des tâches et la conception fonctionnelle. Ils nous ont dit ce qui devait être fait, nous l'avons fait, puis ils ont testé et accepté les résultats. La vitesse de mise en œuvre a augmenté, mais bientôt une telle organisation du flux de travail a dû être révisée: le consultant financier allemand est parti en vacances pendant trois semaines. Pour le projet, ce délai est devenu critique, les tâches principales pour nous étaient précisément liées aux finances, aux impôts et autres. Je devais également prendre en charge cette partie. En conséquence, nos experts ont compris que la législation fiscale européenne n'était pas bien pire que la législation externe.
De plus, il y avait constamment des tâches non standard. Grâce à l'immersion profonde de la principale équipe russe en développement, ils ont pu les résoudre relativement rapidement. De plus, les solutions ont été initialement développées en tenant compte de la connaissance de tous les systèmes et processus utilisés dans notre entreprise.
L'une de ces tâches est l'intégration d'un nouvel environnement cloud avec le système ERP russe existant. Il implémentait déjà des fonctionnalités liées au travail des acheteurs, et nous ne voulions pas dupliquer le code afin de ne pas compliquer son support. En conséquence, les commandes d'achat de marchandises auprès de fournisseurs étrangers sont créées dans l'ERP russe, puis transférées vers le cloud allemand.
Dans le processus de mise en œuvre, l'équipe russe a maîtrisé une approche complètement nouvelle du développement pour nous et de nouveaux outils. Nous avions l'habitude d'utiliser notre propre IDE pour Axapta, mais ici nous sommes passés à Visual Studio et Azure DevOps. Au cours de la mise en œuvre du projet, les versions des logiciels ont changé et nos spécialistes connaissaient tous les plaisirs du développement parallèle pour les environnements cloud - en termes techniques, c'était très intéressant.
SureStep vs Agile: problèmes de lancement
Des collègues allemands ont travaillé selon la méthodologie Microsoft SureStep. Il s'agit d'une approche inflexible plus proche de la «cascade» classique. Cela implique à chaque étape la documentation de tout, la préparation de conceptions fonctionnelles et techniques, des tests rigoureux avec la publication de protocoles, l'enregistrement des processus dans certains systèmes de modélisation, etc. Avec une demande pour une telle documentation, des collègues nous ont contactés un mois avant le lancement. À cette époque, le nouveau système ERP fonctionnait déjà plus ou moins. En supposant de le lancer dans six mois, nous avons choisi des méthodes de développement plus flexibles: stand-ups quotidiens, discussion des tâches et sorties hebdomadaires. Pour la documentation, nous avons utilisé des éléments de travail dans Azure DevOps, ils reflétaient également l'avancement du projet et confirmaient les résultats du test.
Le système étant trouble, la décision finale de sa sortie en production a été prise par Microsoft, tous les contacts ayant été pris par nos sous-traitants. À leur tour, ils n'étaient pas prêts à envoyer une candidature sans toute la documentation nécessaire du point de vue de la méthodologie SureStep. En conséquence, le lancement en temps voulu du projet était menacé.
Nous avons décidé de contacter le fournisseur par nous-mêmes et avons reçu l'approbation pour entrer en production, après quoi nous avons calmement et systématiquement amélioré les fonctionnalités du système par nous-mêmes. Des experts allemands nous ont aidés à transférer les paramètres de l'environnement de test à l'épicerie. Après cela, ils ont mis en place la comptabilité et corrigé les lacunes si nous avions des commentaires.
Test de bataille
Grâce à l'implication opportune de notre propre équipe, nous avons réussi à respecter les délais et à lancer le système le 1er janvier 2019, comme prévu initialement.
Le nouveau système comptable a combiné la partie financière et la logistique, nous l'avons déjà passé en revue les rapports trimestriels en Allemagne. Avant cela, nous avons réussi à réaliser la soi-disant clôture du mois sans perte significative de terme. Lors du lancement de cette classe de systèmes, les retards sont inévitables, mais en janvier, nous avions trois jours de retard et en février, un seul. Alors que nous collectons les données du système manuellement, l'équipe de développement russe est maintenant engagée dans l'automatisation des rapports. Les problèmes sont principalement liés au facteur humain: il est difficile pour les employés d'effectuer de nouvelles procédures pour eux, et une certaine rugosité est sûre de sortir.
Nous avons maintenant une image transparente des marchandises au niveau du numéro de magasin individuel (SKU) et des données sur les soldes dans les entrepôts européens intermédiaires. Il n'a pas été possible de clôturer un certain nombre de tâches jusqu'au bout: il y a des difficultés d'intégration avec une banque allemande et un certain nombre de problèmes mineurs pour la résolution rapide dont les ressources de l'équipe interne n'étaient pas suffisantes - il était initialement supposé que le contractant fermerait ce front. Fondamentalement, tout se résume à l'absence d'un niveau d'automatisation approprié et à une certaine augmentation de la quantité de travail manuel pour les utilisateurs finaux. Maintenant, nous comblons progressivement les lacunes avec les forces de notre équipe et avec l'aide d'un nouveau partenaire avec une succursale en Russie.
Le bonus que nos développeurs ont travaillé sur le projet était également le fait qu'immédiatement au stade de la mise en œuvre, des améliorations ont été apportées pour améliorer la fonctionnalité du système.
L'équipe russe a développé une détermination automatique de la taxe sur les commandes d'achat et de vente. Par défaut, le système demande au comptable de définir manuellement le régime fiscal lors du traitement de la facture et de l'enregistrement des transactions. Dans ce cas, il est nécessaire de prendre en compte le pays d'expédition, le pays d'immatriculation du fournisseur, qui ramasse les marchandises (destinataire ou fournisseur), qui envoie les marchandises à la Fédération de Russie (entité juridique allemande ou russe), que les marchandises soient prises directement du fournisseur en Russie ou que la cargaison soit consolidée en Europe. Le comptable n'a pas toutes ces subtilités pour chaque livraison. Nous avons entièrement automatisé le processus dans le système afin que le prestataire logistique responsable introduise les paramètres initiaux nécessaires. En outre, le système, sur la base des paramètres créés, détermine lui-même le régime fiscal et les écritures comptables nécessaires. Toutes les données sont automatiquement consolidées dans les rapports statistiques nécessaires pour l'Allemagne et la déclaration de revenus. Ainsi, les responsabilités sont mieux réparties entre les spécialistes, la rapidité et la fiabilité du travail augmentent.
Résumé
Au départ, nous espérions que la plupart des travaux incomberaient à l'entrepreneur et, par conséquent, tous les blocs clés ont été fabriqués par notre propre développement. En règle générale, le lancement de l'ERP prend 1 an, mais nous avons réussi à démarrer 6 mois après le lancement du projet, dont le développement actif n'a duré que 3 mois.
En conséquence, nous avons eu une expérience unique, que nous avons décidé de partager. La coopération avec des entrepreneurs étrangers qui connaissent les conditions locales est pratique, mais vous ne devez pas vous attendre à des miracles de leur part. Si vous avez
votre propre équipe solide , vous devez externaliser uniquement le conseil et la définition des tâches, ainsi que les tests.
Ce n'est pas la fin de notre histoire. Un nouveau défi est associé à l'introduction en Russie d'un système national unifié de marquage des marchandises. Les législateurs ont reporté sa date de lancement à 2020, mais à partir de juillet, nous voulons marquer chaque paire de chaussures avec un code à barres unique avant de passer la douane. De plus, il existe toujours des tâches liées à l'optimisation des performances. Eh bien, il y a plein d'autres idées et plans. Dans leur mise en œuvre, nous nous appuierons désormais davantage sur nos propres forces, pour lesquelles nous devrons d'abord «grossir» un peu.