إن الجمع بين النظم المحاسبية للفرع البعيد وتكاملها مع الهيكل الرئيسي مهمة صعبة إلى حد ما حتى داخل روسيا. وعندما يكون العميل في الخارج ، يمكن للمشروع بأكمله أن يعقد عدم وجود خبرة في قوانين الضرائب المحلية وتعارض العقلية. اسمي ستانيسلاف غوتز ، أنا رئيس قسم تطوير أنظمة لامودا لتخطيط موارد المؤسسات ، وسأخبركم في هذا المقال فقط عن هذه التجربة - حول تطبيق نظام تخطيط موارد المؤسسات في فرعنا الألماني.
تقوم الشركة الفرعية الألمانية بشراء البضائع وبيعها لكيان قانوني روسي. سمح نظام Tsenit المستخدم فيه بحفظ السجلات فقط على مستوى البيانات المالية: من ، من ، ومقدار الأموال المستحقة ، عند الشراء أو البيع ، إلخ. كان من المستحيل إجراء محاسبة على البضائع والمهام اللوجيستية باستخدام أدوات Tsenit ؛ لحل هذه المشكلات ، يجب استخدام أدوات إضافية ، مما أثر سلبًا على سرعة وموثوقية النظام بأكمله. وكانت البيانات نتيجة لذلك مبعثرة عبر عدة قواعد بيانات.
بالإضافة إلى ذلك ، يجب على الكيان القانوني الألماني تقديم تقارير ودفع الضرائب وإقرار عمليات التدقيق - ومع أنظمة المحاسبة الحالية ، لم يكن من السهل حل هذه المشكلات.
لفهم سبب إجراء هذه الصفقة المالية أو تلك في Tsenit وللإجابة على أسئلة بسيطة من السلطات الضريبية أو مراجعي الحسابات ، كان علي أن أجرف كميات هائلة من البيانات يدويًا في Excel والاتصال بقسم الخدمات اللوجستية.
في مرحلة ما ، تقرر الجمع بين المحاسبة والمالية والخدمات اللوجستية في دائرة واحدة في إطار نظام واحد لتخطيط موارد المؤسسات. كما تم اختيار البرنامج الرئيسي Microsoft Dynamics 365 - Dynamics AX السابق ، أو حتى أسهل - Axapta. لا يوجد ما يقرب من العملاء الروس الذين يستخدمون الحل السحابي لهذا النظام (وبصورة أكثر دقة ، أصبحنا ثانيًا) ، ولكنه كان الأنسب لأغراضنا.
التوقيت والميزانية والإيمان بمستقبل مشرق
كانت لدينا حدود زمنية صارمة: كان إطلاق مثل هذا النظام في منتصف السنة المالية يتطلب نقل مجموعة كاملة من البيانات التاريخية ، والتي ستكون مهمة مستحيلة ، لأنه في النظام القديم ، كانت محاسبة البضائع غائبة فعليًا وأُبقيت في جداول البيانات. لكن في بداية الفترة المشمولة بالتقرير ، يكفي تحويل الأرصدة فقط. وبالتالي ، كان من الضروري إطلاق إما 1 يناير 2019 ، أو تأجيله لمدة سنة أخرى. العمليات المرتبطة بالعمليات اللوجستية والمستودعات ليست معقدة بشكل خاص ، ويبدو لنا أنه لن تكون هناك مشاكل في المواعيد النهائية.
بالإضافة إلى المواعيد النهائية ، كانت هناك مشكلة في الميزانية: نشر وصيانة البنية التحتية لتكنولوجيا المعلومات الخاصة بك في ألمانيا وشراء تراخيص برامج الشركات باهظة الثمن لكل مستخدم.
نظرًا لأن أكثر من 20 شخصًا يشاركون في عمليات الأعمال الألمانية ، فقد استقرنا على حل Dynamics 365 السحابي ، وبالنسبة إلى الفروع البعيدة الصغيرة ، فإن مخطط SaaS هو الأمثل ، حيث يتيح لك الحصول على جميع بيئات البرمجيات والتطوير اللازمة لبدء التنفيذ فور توقيع العقد مع المزود.
تعد سياسة ترخيص Microsoft Dynamics 365 بسيطة للغاية وتتحمل سعرًا ثابتًا لترخيص مستخدم واحد شهريًا ، في حين يمكن زيادة أو تقليل عدد المستخدمين. كانت هذه حجة أخرى لاختيار منتج البرنامج هذا بالتحديد.
المزالق
تكمن المشكلة الرئيسية خارج المستوى الفني: لم نكن نعرف جميع متطلبات التشريعات الأوروبية لحفظ السجلات في مثل هذه الأنظمة. يغطي Microsoft Dynamics 365 عددًا كبيرًا من العمليات التجارية ؛ يتم إصدار حزم التوطين المزعومة التي تسمح لك بتخصيص الحل بمرونة مع تفاصيل تشريع بلد معين. إذا قام فريق التطوير بدراسة النسخة الروسية لفترة طويلة ، فلن نتمكن من مصادفة نسخة لألمانيا. سيكون إنشاء مثل هذا الحل من قبل فريقك مهمة صعبة.
كانت لدى الإدارة الألمانية مخاوف من أن الجانب الروسي لا يستطيع التعامل مع هذه المهمة بسبب نقص الخبرة والمعرفة في الضرائب والمحاسبة المحلية. نتيجة لذلك ، اخترنا الأرضية الوسطى وجذبنا الاستشارات الخارجية. كان من المفترض سد الفجوات المرتبطة بالمتطلبات القانونية الأوروبية ، وتقديم مراجعة للترحيل من النظام المالي السابق ، وتحليل أوصاف العمليات التجارية ، وتحسينها ، وتناسب الحل المستقبلي مع الاستخدام الأقصى للوظائف القياسية. إذا لزم الأمر ، فقد تم التخطيط لإكمالها ، ما أدى إلى اندماج الفريق الروسي في التطوير.
بدء التنفيذ ونقل البيانات
بشكل افتراضي ، حصلنا على حقوق لثلاث بيئات: BUILD - لتجميع التعليمات البرمجية التي تم إنشاؤها بواسطة مطورين مختلفين في تطبيق واحد ، SAT (اختبار القبول القياسي) - لإجراء اختبار قبول المستخدم ، و PROD - للتشغيل. بالإضافة إلى ذلك ، يتم نشر أجهزة dev-box الافتراضية لكل مطور في Azure. تتم إدارة البنية التحتية بأكملها ومراقبتها من خلال بوابة واحدة - خدمات دورة الحياة ، ومن ميزات عملية التخصيص أن أي تحسينات تدخل بيئة PROD فقط من خلال SAT.
نظرًا لأنه تم اختيار Microsoft Dynamics 365 كنظام جديد ، كان من السهل نسبياً تنفيذ نقل البيانات باستخدام حزم البيانات المتاحة من المربع. يتمتع Dynamics 365 بعلاقة وثيقة مع منتجات Microsoft ، بما في ذلك Excel: بالنسبة للمستخدم ، يبدو وكأنه جدول بيانات متصل بخدمات Dynamics 365 عبر
ODATA . باستخدام امتداد Excel ، نشر المستخدمون البيانات مباشرةً إلى النظام. أعد الجانب الألماني القوالب ، مشيرا إلى الأعمدة المطلوبة فيها. قام المستخدمون بملء هذه القوالب ، وسيطر الاستشاريون على عملية الاستيراد.
من بين أشياء أخرى ، من النظام المحاسبي القديم ، قام الاستشاريون بنقل المعلومات حول الموردين والعملاء ، وكذلك الأرصدة في حسابات دفتر الأستاذ العام. يتطلب النقل المباشر لجميع البيانات المتعلقة بالبضائع وقتًا وجهدًا كبيرًا ، وحاولنا حل هذه المشكلة بطريقة أكثر فعالية. تم دمج نظام المحاسبة الجديد للفرع الألماني مع النظام الروسي الرئيسي ، حيث توجد البيانات الرئيسية الخاصة بالسلع. في نهاية العام ، لم يكن لدينا أرصدة مادية في ألمانيا ، ونتيجة لذلك ، كان من الضروري نقل المعلومات الأساسية الضرورية من النظام القديم لمزيد من التوزيع للسلع من النظام القديم. وبالتالي ، كان من الممكن الاستغناء عن نقل جميع البيانات التاريخية على البضائع ، مما وفر الوقت.
نصف الاستعانة بمصادر خارجية: ربط الفريق الروسي
بعد أن بدأ التنفيذ في يونيو 2018 ، توقعنا حل جميع المشكلات قبل عطلة رأس السنة الجديدة ، ولكن بالإضافة إلى مشاكل اللغة الطبيعية في مثل هذه المشاريع ، ظهرت صعوبات التواصل. لقد استجاب الاستشاريون الألمان لفترة طويلة للاستفسارات. لا يمكن للموظف العمل دون انقطاع لأكثر من 6 ساعات متتالية. بعد الانتهاء من العمل ، يجب أن يكون لديه ما لا يقل عن 11 ساعة من وقت الفراغ من العمل. وعندما يتعامل متخصص مع عميل آخر ، لا يمكن أن يسأل عن أي شيء. وقد أثر هذا النهج الرسمي على التوقيت. في مرحلة ما ، اقترح المقاول العام الجديد إطلاق المحاسبة المالية فقط ، والتي عملت بالفعل في النظام القديم. هذا لم يناسبنا. منذ عام 2013 ، قمنا بتنفيذ Axapta بشكل مستقل في Lamoda ، وفي عام 2016 قمنا بنقل جميع الحسابات بالكامل من 1C إليها. العمليات في روسيا أكثر تعقيدًا ، لذلك عرفنا أن المشروع يمكن أن يكتمل في الوقت المحدد.
قررنا جذب الفريق الروسي ، مع الأخذ من زملائنا من ألمانيا كل التخصيص وتطوير وظائف النظام. في الواقع ، تركنا للمقاول الخارجي فقط الاستشارات وتحديد المهام والتصميم الوظيفي. أخبرونا بما يجب القيام به ، لقد فعلنا ذلك ، ثم اختبروا النتائج وقبلوها. زادت سرعة التنفيذ ، ولكن سرعان ما تطلبت مثل هذه المنظمة لسير العمل المراجعة: ذهب المستشار المالي الألماني في إجازة لمدة ثلاثة أسابيع. بالنسبة للمشروع ، أصبح هذا الموعد النهائي حاسمًا ، وكانت المهام الرئيسية بالنسبة لنا مرتبطة بدقة بالتمويل والضرائب وما شابه. كان عليّ أن أتولى هذا الجزء أيضًا ، ونتيجة لذلك ، توصل خبراؤنا إلى التشريعات الضريبية الأوروبية التي لم تكن أسوأ من التشريعات الخارجية.
بالإضافة إلى استمرار وجود بعض المهام غير القياسية. بفضل الانغماس العميق للفريق الروسي الرئيسي في التنمية ، تمكنوا من حلها بسرعة نسبيا. بالإضافة إلى ذلك ، تم تطوير الحلول في البداية مع مراعاة المعرفة بجميع الأنظمة والعمليات المستخدمة في شركتنا.
إحدى هذه المهام هي دمج بيئة سحابة جديدة مع نظام ERP الروسي الحالي. لقد نفذت بالفعل وظيفة متعلقة بعمل المشترين ، ولم نكن نريد تكرار الكود حتى لا نعقد دعمه. نتيجة لذلك ، يتم إنشاء أوامر شراء البضائع من موردين أجانب في نظام تخطيط موارد المؤسسات الروسي ثم نقلها إلى السحابة الألمانية.
في عملية التنفيذ ، أتقن الفريق الروسي نهجا جديدا تماما للتنمية بالنسبة لنا وأدوات جديدة. اعتدنا على استخدام IDE الخاصة بنا لـ Axapta ، ولكن هنا انتقلنا إلى Visual Studio و Azure DevOps. أثناء تنفيذ المشروع ، تغيرت إصدارات البرامج ، وكان أخصائونا يعرفون كل مسرات التطوير الموازي للبيئات السحابية - من الناحية الفنية ، كان الأمر ممتعًا للغاية.
SureStep مقابل رشيق: إطلاق القضايا
عمل الزملاء من ألمانيا وفقًا لمنهجية Microsoft SureStep. هذا هو نهج غير مرن هو أقرب إلى "الشلال" الكلاسيكية. يتضمن في كل مرحلة توثيق كل شيء ، وإعداد التصميمات الفنية والتقنية ، واختبار صارم مع إصدار البروتوكولات ، وتسجيل العمليات في بعض أنظمة النمذجة ، إلخ. مع طلب للحصول على مثل هذه الوثائق ، اتصل بنا الزملاء قبل شهر من الإطلاق. كان نظام ERP الجديد بحلول ذلك الوقت يعمل بشكل أو بآخر. على افتراض إطلاقها في غضون ستة أشهر ، اخترنا أساليب تطوير أكثر مرونة: المواقف اليومية ومناقشة المهام والإصدارات الأسبوعية. للتوثيق ، استخدمنا عناصر العمل في Azure DevOps ، كما أنها تعكس تقدم المشروع وأكدت نتائج الاختبار.
نظرًا لأن النظام غائم ، فقد اتخذت Microsoft القرار النهائي بشأن إصداره في الإنتاج ، حيث تم تنفيذ جميع الاتصالات من قبل مقاولينا. إنهم ، بدورهم ، لم يكونوا مستعدين لإرسال طلب دون جميع الوثائق اللازمة من وجهة نظر منهجية SureStep. نتيجة لذلك ، كان إطلاق المشروع في الوقت المناسب في خطر.
قررنا الاتصال بالمورد بمفردنا وتلقينا الموافقة على الدخول في الإنتاج ، وبعد ذلك قمنا بتحسين وظائف النظام بهدوء وبشكل منهجي من تلقاء نفسه. ساعدنا الخبراء الألمان في نقل الإعدادات من بيئة الاختبار إلى البقالة. بعد ذلك ، قاموا بإعداد المحاسبة وتصحيح أوجه القصور إذا كان لدينا أي تعليقات.
اختبار المعركة
بفضل مشاركة فريقنا في الوقت المناسب ، تمكنا من الوفاء بالمواعيد النهائية وإطلاق النظام في 1 يناير 2019 ، كما كان مخططًا له في الأصل.
لقد جمع نظام المحاسبة الجديد بين الجزء المالي واللوجستيات ، لقد مررنا بالفعل من خلال التقارير الفصلية في ألمانيا. قبل ذلك ، تمكنا من تنفيذ ما يسمى إغلاق الشهر دون خسارة كبيرة من حيث. عند بدء تشغيل هذه الفئة من الأنظمة ، تكون التأخيرات حتمية ، لكن في شهر يناير تأخرنا ثلاثة أيام ، وفي فبراير - واحد فقط. بينما نقوم بجمع البيانات من النظام يدويًا ، يشارك فريق التطوير الروسي الآن في أتمتة التقارير. ترتبط المشكلات بشكل أساسي بالعامل البشري: من الصعب على الموظفين تنفيذ إجراءات جديدة لهم ، ومن المؤكد أن هناك بعض الخشونة.
الآن لدينا صورة شفافة للبضائع على مستوى رقم المستودع الفردي (SKU) وبيانات عن الأرصدة في المستودعات الأوروبية الوسيطة. لم يكن من الممكن إغلاق عدد من المهام حتى النهاية: هناك صعوبات في الاندماج مع أحد البنوك الألمانية وعدد من المشاكل البسيطة لحلها في الوقت المناسب والتي لم تكن موارد الفريق الداخلي كافية - كان من المفترض في البداية أن يغلق المقاول هذه الجبهة. في الأساس ، كل هذا يتلخص في عدم وجود مستوى مناسب من التشغيل الآلي وبعض الزيادة في كمية العمل اليدوي للمستخدمين النهائيين. نحن الآن نسد الفجوات تدريجياً مع قوى فريقنا وبمساعدة شريك جديد له فرع في روسيا.
كانت المكافأة التي عمل عليها مطورونا في المشروع هي حقيقة أنه في مرحلة التنفيذ مباشرة ، تم إجراء تحسينات لتحسين وظائف النظام.
طور الفريق الروسي تحديدًا تلقائيًا للضريبة على أوامر الشراء والبيع. افتراضيًا ، يتطلب النظام من المحاسب تعيين نظام الضريبة يدويًا عند معالجة الفاتورة ونشر المعاملات. في هذه الحالة ، من الضروري مراعاة بلد الشحن أو بلد تسجيل المورد الذي يلتقط البضاعة (المستلم أو المورد) ، الذي يرسل البضاعة إلى الاتحاد الروسي (الكيان القانوني الروسي أو الروسي) ، سواء كانت البضاعة مأخوذة مباشرة من المورد إلى روسيا أو يتم توحيد البضائع في أوروبا. لا يملك المحاسب كل هذه التفاصيل الدقيقة لكل عملية تسليم. قمنا بأتمتة العملية في النظام بشكل كامل بحيث يقدم المزود اللوجستي المسؤول المعلمات الأولية اللازمة. علاوة على ذلك ، فإن النظام على أساس الإعدادات التي تم إنشاؤها نفسها يحدد نظام الضرائب وإدخالات المحاسبة اللازمة. يتم دمج جميع البيانات تلقائيا في التقارير الإحصائية اللازمة لألمانيا والإقرار الضريبي. وبالتالي ، يتم توزيع المسؤوليات بشكل أفضل بين المتخصصين ، تزداد سرعة وموثوقية العمل.
النتائج
في البداية ، كنا نأمل أن يقع الجزء الأكبر من العمل على المقاول ، ونتيجة لذلك ، تم تطوير جميع الكتل الرئيسية من خلال تطويرنا. عادةً ما يستغرق إطلاق ERP من عام واحد ، لكننا تمكنا من البدء بعد 6 أشهر من بدء المشروع ، واستمر التطوير النشط 3 أشهر فقط.
نتيجة لذلك ، حصلنا على تجربة فريدة ، قررنا مشاركتها. إن التعاون مع المقاولين الأجانب الذين يعرفون الظروف المحلية أمر عملي ، لكن يجب ألا تتوقع المعجزات منهم. إذا كان لديك
فريق قوي خاص بك ، فيجب عليك الاستعانة بمصادر خارجية للاستشارات وإعداد المهام فقط ، وكذلك الاختبار.
هذه ليست نهاية قصتنا. يرتبط التحدي الجديد بإدخال نظام وطني موحد لتمييز البضائع في روسيا. أرجأ المشرعون تاريخ إطلاقه إلى عام 2020 ، لكن من يوليو نريد أن نميز كل زوج من الأحذية برمز شريطي فريد قبل المرور عبر الجمارك. بالإضافة إلى ذلك ، هناك دائمًا مهام مرتبطة بتحسين الأداء. حسنًا ، هناك الكثير من الأفكار والخطط الأخرى. في تنفيذها ، سوف نعتمد الآن أكثر على نقاط القوة الخاصة بنا ، والتي سيتعين علينا أولاً "سمينها" قليلاً.