الترحيل من نظام ERP إلى آخر

في كثير من الأحيان ، لا يؤدي انتقال الشركة إلى نظام ERP جديد إلى إيقاف التكاليف المالية للشراء والانتهاء ، ولكن الحاجة إلى الترحيل من النظام القديم. لديهم المئات أو حتى الآلاف من المستخدمين الذين ينفذون عمليات أعمالهم في أحد البرامج ، ويحتاجون بطريقة ما إلى نقلهم جميعًا إلى برنامج آخر دون توقف للعمل.

في السنوات الأخيرة ، ذهبنا بهذه الطريقة عشرات المرات ، وقمنا بالفعل بتطوير أقل الطرق المؤلمة للقيام بذلك.

الصعوبات

اليوم الذي كرمت فيه بيسون قريتك بحضوره ، أصبح بالنسبة لك أهم شيء في الحياة. ولكن بالنسبة لي كان يوم الثلاثاء.
- بيسون ، ستريت فايتر

غالبًا ما تكون عملية الانتقال معقدة بسبب حقيقة أن العديد من الموظفين الذين لديهم انطباع خاص لدى العميل في حالة من الذعر لأول مرة ، لأن هذا هو على الأرجح بالنسبة لهم أول هجرة في حياتهم المهنية. بالنسبة لنا ، يعد هذا حدثًا عاديًا ، كقاعدة عامة ، يتم وفقًا لنفس السيناريو.

عندما يتبادل أي شخص منتجًا لآخر ، فإن أول ما يلاحظه هو أنه قد أخذ منه ولم يدرك بعد ما حصل عليه. لذلك ، غالبًا ما يكون رد الفعل الأول هو: "ما هذا الهراء الذي ألقيتني به هنا - افعل كما كان" في الممارسة العملية ، كان لدينا موقف حيث اشتكى أحد المستخدمين من أنه غير مرتاح للإجراء الجديد ، والذي تم في النظام القديم في خمسة انتقالات بين النماذج. لكنه كان يتقن مثل هذه الآلية التلقائية بحيث كان بالنسبة لشخص ما أسرع في البداية من القيام بعملين جديدين ، ولكن أبسط من ذلك بكثير.

صعوبة أخرى هي أنه أثناء الانتقال ، يحب العملاء تغيير العمليات التجارية إلى رؤيتهم. يجب التعامل مع هذا بعناية فائقة ، حيث أن العمليات الحالية "كما هي" مضمونة للعمل. العمليات المضمنة في المنتج ، كقاعدة عامة ، تعمل أيضًا ، حيث يتم استخدامها من قبل عملاء آخرين. لكن الاختراعات الجديدة قد تبدو جميلة من الناحية النظرية ، لكن في الممارسة العملية ستصطدم بتافه ، والتي بسببها يمكن أن تتوقف العملية برمتها.

سيناريوهات

في الممارسة العملية ، هناك سيناريوهان رئيسيان للانتقال من نظام إلى آخر:

طلقة واحدة

يتم تحديد تاريخ الانتقال إلى النظام الجديد. تم تطوير جميع الوظائف لتفريغ البيانات من النظام القديم وتحميلها إلى نظام جديد. في اليوم العاشر ، تبدأ عملية الترحيل في الليل ، وفي الصباح ، يبدأ جميع المستخدمين الذين يستخدمون جميع العمليات التجارية في العمل في النظام الجديد بطريقة جديدة.

كل شيء جميل على الورق. ولكن في الممارسة العملية هناك أربع فئات على الأقل من المشاكل:

1. التدريب . في وقت الانتقال ، وكقاعدة عامة ، ينسى العديد من المستخدمين المدربين تمامًا ما تم تدريسه. يبدأون في كزة كل شيء ، ونتيجة لذلك توقفوا عن العمل بكلمات "لا شيء يعمل". يمكن حل هذه المشكلة بمساعدة موظفي الدعم من الخط الأول الذين يمكنهم المساعدة في هذه اللحظة. ولكن سيكون هناك الكثير من هذه الطلبات في اليوم الأول من عملية النقل بحيث يكون من المستحيل الوفاء بها بعدد الموظفين المتاح. أو تحتاج إلى الحصول على وسيلة لتوسيع عددهم بسرعة أثناء النقل ، وهو أمر صعب للغاية أيضًا.
2. التحسينات والأخطاء . كقاعدة عامة ، يجلب نظام ERP جديد عمليات تجارية جديدة (وإلا فلماذا يغيره). من الواضح أنه قبل التنفيذ مباشرة ، تم طردهم بطريقة أو بأخرى ، ولكن في وقت "التحقق من المعركة" الحقيقي ، عادة ما تظهر كمية كبيرة من الفروق الدقيقة ، بسبب العمليات التي لا يمكن تنفيذها في كثير من الأحيان. وفقًا لذلك ، يتزايد عدد مثل هذه التحسينات ذات الأولوية المباشرة مثل كرة الثلج ، وهناك حاجة ماسة إلى موارد المبرمجين التي لن تتمكن فعليًا من إغلاق مثل هذا العدد من الطلبات.
3. البيانات . عادةً ما يكون مطورو النظام القديم غير مهتمين جدًا بالمساعدة في تحميل البيانات (بالنسبة لهم ، يعد هذا حدثًا محزنًا بشكل عام لفقدان عميل) ، وإذا ساعدوا ، فإن جودة التحميل تترك الكثير مما هو مرغوب فيه. توجد حالات عدم تناسق ، كقاعدة عامة ، في الأيام الأولى لتشغيل النظام الجديد. نتيجة لذلك ، يجب تصحيح عملية التفريغ وإعادة تحميل البيانات بطريقة ما ، مع مراعاة التغيير الذي تم تغييره بالفعل أثناء التشغيل.
4. الأداء . أثناء عملية الاختبار ، ليس من السهل إعادة إنتاج الحمل "الحقيقي" بالكامل على النظام. إذا كانت الوظيفة الأساسية للمنتج عادةً مختبرة بالفعل وتُظهر معلمات الأداء العادية ، فإن التحسينات "الشخصية" للعميل قد "تجلس" في ظروف معينة على الخادم. وهذا بدوره يتطلب أيضًا موارد مبرمج للتحسين.

عندما تحدث كل هذه المشكلات الأربع في اليوم الأول أو الأسبوع الأول من الانتقال في نفس الوقت ، لا يمكن تجنب خسائر العمل. لذلك ، فإن مثل هذا المخطط لا يعمل بشكل فعال إلا في المشروعات الصغيرة. على سبيل المثال ، عندما يكون عدد المستخدمين أقل من مائة والعمليات ليست حرجة.

من الواضح أنه يمكنك إنفاق المزيد من الموارد على التدريب واختبار النظام مباشرة قبل الانتقال ، وبعد ذلك ستكون هناك مشاكل أقل. لكن في الحياة ، يشير موظفو العميل عادة إلى هذه العمليات "بلا أكمام" ويعتمدون على "ربما". أو أنهم ببساطة مخطئون ، ويتوقعون أن تتمكن عملية معينة من كسب المال في بيئة معينة ، ولكن في الواقع ، يبدو أن الفروق الدقيقة البسيطة ستخفض كل شيء.

تدريجي

مع هذا النهج ، يتم تقسيم النظام أفقياً (حسب العمليات) أو رأسياً (بواسطة المستخدمين) إلى أجزاء ، والتي يتم تقديمها بدورها واحدة تلو الأخرى. هذا يسمح لك بنشر جميع المشاكل المذكورة أعلاه في الوقت المناسب وحلها لأنها تحصل على طاقة أقل.

علاوة على ذلك ، سوف أصف عملية ترحيل نظام ERP استنادًا إلى منصة lsFusion المفتوحة والحرة لسلسلة متاجر البيع بالتجزئة ، نظرًا لأننا متخصصون في هذه الصناعة. لكننا طبقنا نفس المبدأ على العملاء من المناطق الأخرى.

قراءة البيانات

عادة ، بالنسبة للشركات التي تدعم النظام القديم ، فإن الأخبار المتعلقة باستبدال البرنامج وفقدان عميل هي ضربة كبيرة. يقع البعض في حالة غير كافية ويبدأ في تهديد العميل بوقف فوري للدعم. بطبيعة الحال ، هذا لا يعمل أبداً ، ولا يمكن أبداً عكس القرار. ومع ذلك ، نادراً ما يكون من الممكن الاتفاق مع أولئك الذين يدعمون النظام القديم على أنهم يقدمون جداول حيث يتم تخزين جميع البيانات اللازمة لعملية النقل.

أولاً ، تحتاج إلى تحديد البيانات التي يتم تخزين DBMS الضرورية فيها وكيفية الوصول إليها. خلال السنوات القليلة الماضية ، كان علينا التعامل مع قواعد بيانات إدارة قواعد البيانات التالية التي عملت بها الأنظمة القديمة:

• الوصول. نظرًا لأن النظام الأساسي مكتوب بلغة Java ، فقد كان من الممكن البحث عن مكتبة قديمة كانت تعرف كيفية الاتصال بـ mdb (على الرغم من أنها للقراءة فقط). لقد نجح هذا الأمر بشكل خاص ، لأنه على الرغم من الفلاتر ، فإنه يقرأ الجدول بأكمله ، ولكنه مع ذلك كان كافياً. لقد كنا محظوظين لأن خدمة تكنولوجيا المعلومات الخاصة بالعميل كانت تعرف بنية قاعدة البيانات جيدًا وأخبرنا ماذا وأين يتم تخزينها.
• مرض التصلب العصبي المتعدد مزود كان النظام القديم هو Axapta 2000s. لقد تم إعداد الوصول إلى نظام الاختبار ، حيث أطلقنا واجهة المستخدم الرسومية و SQL Profiler. ثم تناوبنا في الأدلة ، ونظرنا في ما يطلبه Axapta. كان من السهل أن نفهم منهم بالضبط أين يتم تخزين هذه المعلومات أو تلك.
• البصرية Foxpro كان كل شيء بسيطًا ، حيث كان هناك انتقال من أنظمتنا القديمة ولم يكن من الصعب الحصول على المعلومات. كانت الصعوبة الوحيدة هي العثور على مكتبة Java التي لا تعمل مع جداول DBASE ، ولكن بتنسيق Visual Foxpro.
• أوراكل. الانتقال من برنامج محاصر supermag. لقد عملنا وفقًا لنظام مشابه لنظام Axapta: واجهة المستخدم الرسومية والاستعلامات في SQL Developer للاستعلامات الأكثر حداثة. كانت البنية الأساسية والواجهات هناك أبسط بكثير مما كانت عليه في Axapta ، لذلك لم تكن هناك مشاكل كبيرة.
• التقدم / OpenEdge . الانتقال من برنامج الجستوري المعبأ. بالنظر إلى أن نظام إدارة قواعد البيانات ، بعبارة ملطفة ، ليس شائعًا على الإطلاق ، لم نجد أي ملفات تعريف. ومع ذلك ، كان هناك تفريغ في الملفات النصية. جعل ذلك من الممكن ببساطة الدخول إلى واجهة المستخدم الرسومية لخادم الاختبار والبحث من خلال الملفات النصية للبحث عن البيانات التي تظهر على الشاشة. لحسن الحظ ، هناك فرصة لتنزيل برنامج تشغيل JDBC على الموقع الرسمي لهذا DBMS ، وتقديم استفسارات إلى قاعدة بيانات SQL. ثم كانت مسألة تقنية.

وبفضل هذه الأساليب ، لم أضطر مطلقًا إلى اللجوء إلى مطوري النظام القديم ، مما أدى إلى توفير نفقات العملاء بشكل كبير ، حيث عادةً ما يقومون ببساطة بتوزيع مبالغ ضخمة من المال للتعاون.

البيانات الرئيسية

كل شيء يبدأ باستيراد البيانات الرئيسية. على وجه الخصوص ، بالنسبة لتجارة التجزئة ، فإن واردات أدلة مجموعات البضائع والسلع والمقاولين والمتاجر هي أول من يتحقق. مع الانتقال التدريجي ، هناك طريقتان لاستيراد البيانات الرئيسية:

• استيراد البيانات لمرة واحدة ، ثم إدخال مزدوج في النظام القديم والجديد.
• التحديث التدريجي المستمر للبيانات من النظام القديم إلى النظام الجديد.

هناك حالات عند استخدام النهج الأول ، ولكنها تستغرق وقتًا طويلاً للغاية وتكون عرضة بشكل كبير للعامل البشري مع احتمال حدوث أخطاء. لذلك ، نستخدم دائمًا الخيار الثاني فقط.

من الناحية المثالية ، يمكن للنظام القديم أن يجمع التغييرات ويبلغ بطريقة أو بأخرى أنه يحتاج إلى إعادة استيرادها. لكن في العادة لن يقوم أي شخص بتغيير أو تعديل أي شيء في النظام القديم. لذلك ، فإن نظام العمل الوحيد الذي نستخدمه هو كما يلي:

1. هناك طلب إلى دليل النظام القديم ، والذي يقرأ جميع البيانات منه.
2. تتم مقارنة بيانات القراءة مع الحالي في النظام الجديد ويتم اكتشاف التغييرات.
3. تتم كتابة التغييرات في معاملة واحدة للنظام الجديد.

سيبدو الرمز الموجود على النظام الأساسي لاستيراد دليل المنتج كما يلي:

هذا سوف يعمل على النحو التالي:

• قراءة يراعي الدليل بأكمله مع رمز واسم في الذاكرة
• سيقوم IMPORT بكتابة جميع البيانات إلى الخصائص المحلية (وهي الجداول المؤقتة في قاعدة البيانات)
• ستنشئ الدورة الأولى جميع البضائع التي لم تدخل بعد في قاعدة البيانات الجديدة (البحث عن طريق رمز المنتج). على الرغم من حقيقة أن FOR مكتوب هناك ، فإنه يتم تجميعه في استعلام واحد إلى قاعدة البيانات ، والتي ستعمل فقط مع الجداول المؤقتة.
• ستقوم الدورة الثانية بتحديث الحقول لجميع المنتجات (بما في ذلك تلك التي تم إنشاؤها حديثًا). في هذه الحالة ، سيتم كتابة القيم التي تم تغييرها فقط في الجداول المؤقتة.
• الإجراء الثالث DELETE يكتشف كل البضائع الموجودة في قاعدة البيانات الجديدة ، ولكن ليس في بيانات القراءة وسيحذفها.
• سيتم بدء تطبيق المعاملة وكتابة جميع التغييرات في قاعدة البيانات بناءً على الجداول المؤقتة التي تم إنشاؤها بواسطة الأوامر السابقة.

في الواقع ، يقوم هذا الإجراء في وقت الإطلاق بمزامنة الدليل القديم والجديد تمامًا. لا يخزن أي معلومات إضافية ، لذلك يمكن إعادة تشغيله في أي وقت ، حتى لو تم الانتهاء من التبادل السابق مع وجود أخطاء.

نظرًا لأن كل الإجراءات يتم تصنيفها في استعلامات SQL دون أي تكرار ، يتم كل ذلك بسرعة وأمان. عادة ، استغرق تبادل دليل السلع من 100-200 ألف السجلات بضع دقائق. في الوقت نفسه ، نظرًا لأن PostgreSQL تم إصدارها ، فلن يحدث أي حظر لعمل المستخدم في هذا الوقت.
بنفس الطريقة ، تتم مزامنة أسعار المورّدين ، مصفوفات التشكيلة ، جداول الطلبات والمعلومات الأخرى الضرورية للعمل باستمرار. هنا ، ومع ذلك ، قد تنشأ مشكلة أن منطق المجال في النظام القديم لا يتزامن مع منطق المجال الجديد. على سبيل المثال ، لدينا في نظامنا تاريخ من إصدارات المصفوفة ومفهوم مستويات المنتج داخل المصفوفة. إذا كان النظام الحالي للمحلات في النظام القديم مسطحًا كأداة منطقية للتخزين والبضائع ، فسيتم إنشاء مصفوفة واحدة لكل متجر بمستوى واحد تمامًا.

في أغلب الأحيان ، يمكننا تمكين الإجراء لمزامنة جميع الدلائل مع النظام القديم مرة واحدة في الساعة ، بينما نوفر للمستخدم فرصة لبدء التبادل يدويًا.

هذه العملية

في البيع بالتجزئة ، نقوم عادةً بتقسيم عملية الترجمة رأسيًا بين المتاجر وفي نفس الوقت أفقيًا من عمليات المتجر إلى عمليات المكتب.

الخطوة الأولى هي اختيار متجر واحد حيث سيبدأ النقل إلى النظام الجديد. تستورد الأرصدة الحالية وأسعار المتجر من النظام القديم في شكل مستندات واردة بالكميات والأسعار المقابلة:


قبل بضعة أسابيع من بدء المتجر ، يتم توصيل استيراد التنفيذ من أنظمة نقاط البيع. هذا ضروري حتى تكون هناك بيانات تاريخية لتكوين الأوامر في الأيام الأولى من العمل.

في كثير من الأحيان ، يتم نقل عملية الإنتاج الخاصة في وقت متأخر قليلا عن العمليات الرئيسية. في هذه الحالة ، يتم تنفيذ التفريغ في النظام القديم للوثائق حول حركة المواد الخام واستيراد المنتجات النهائية من هناك.

في يوم النقل ، يبدأ الاستيراد في الليل ، ثم يتم إرسال كل من موظفي دعم العملاء وخط الدعم الأول لدينا إلى المتجر. فهي تساعد المستخدمين على البدء في النظام الجديد دون الاضطرار إلى التدريب المسبق. في هذه الحالة ، عادة ما يتم إغلاق المستندات في النظام القديم لبعض الوقت ، لأن الأشخاص مخطئون ، ويحتاجون إلى القدرة على تصحيح الأخطاء. بعد أسبوعين ، يتم إعادة استيراد البقايا ، ومن ثم تم فرض حظر على التغييرات في النظام القديم.

بعد تحديد جميع المشكلات الموضحة أعلاه وحلها في المتجر الأول ، بعد حوالي أسبوعين يتم نقل 2-3 متاجر أخرى. مرة أخرى التكرار لتحديد وإصلاح المشاكل. ثم يتم ترجمة جميع اللغات الأخرى بسرعة كبيرة ، اعتمادًا على موارد خدمة دعم العملاء للعميل. كل هذا الوقت ، يستمر إدخال البيانات الرئيسية في النظام القديم بحيث تعمل المخازن على النظام القديم.

بعد ذلك ، عندما يتم نقل جميع المتاجر ، قم بإيقاف الاستيراد من النظام القديم بشكل تدريجي أو كليًا ، ويبدأ المستخدمون في إدخال البيانات الرئيسية في النظام الجديد.

يتم الحصول على معلومات موجزة من النظامين القديم والجديد إما في المحاسبة أو في نظام استقصاء المعلومات ، حيث يتم تحميل كلا النظامين في نفس الوقت. هناك يمكنك الحصول على تقارير موجزة عن الفاصل الزمني ، والذي يتضمن الوقت في النظم القديمة والجديدة.

استنتاج

على الرغم من التعقيد الواضح للانتقال من نظام إلى آخر ، بعد السير في هذا المسار عدة عشرات المرات ، أنت تدرك أنه باستخدام مخطط تم تصحيحه ، كل شيء في الواقع ليس مخيفًا للغاية. تنشأ المزيد من المشاكل مع حقيقة أن معظم موظفي العميل محافظون للغاية ، وفي أقل فرصة ، يطلبون القيام "كما كان". وهنا من المهم جدًا أن يكون لدى العميل شخص يتمتع بسلطة كافية يمكنه مقارنة العمليات القديمة والجديدة ، وتحديد العمليات الأكثر ملاءمة وقادرًا على "كسر" الموظفين. أو قم بتعديل العملية وفقًا لمخطط "كما كان" ، إذا اتضح عكس ذلك.