الانتقال من Dynamics GP إلى Business Central: ما الذي يجب توقعه

أخبرتنا مراقبة مالية في شركة تجارية بالشارقة أنها أمضت الأسابيع الثلاثة الأولى بعد الإطلاق تُعيد إنشاء التقارير يدوياً — التقارير ذاتها التي كانت تُشغّلها في Dynamics GP في خمسة وأربعين ثانية. Business Central كان يعمل. البيانات كانت موجودة. لكن لم يُربط أحدٌ SmartLists الخاصة بـ GP ببنية الاستعلامات الجديدة، وسلسلة الموافقات لديها — المُدارة عبر مجموعة WhatsApp وثلاثة ملفات Excel — لم تجد لها موطناً رسمياً في النظام الجديد. نجح الترحيل تقنياً. وتوقّف العمل تشغيلياً.

هذا هو النمط المتكرر. وهو أكثر شيوعاً مما يرغب أي شريك تنفيذي في الاعتراف به.

لماذا يمثّل الانتقال من GP إلى BC تحوّلاً أكبر مما تُدرك معظم الفِرق

بُني Microsoft Dynamics GP بوصفه نظام إدارة مالية مستقلاً. أما Business Central فهو منصة ERP سحابية بالكامل — بنية مختلفة، ونموذج بيانات مختلف، ومنطق تنقل مختلف، وفلسفة مختلفة جوهرياً في طريقة ربط سير العمل. الانتقال من أحدهما إلى الآخر ليس ترقية. إنه استبدال.

التشابه الظاهري يُضلّل الناس. كلاهما يحمل شعار Microsoft. كلاهما يتعامل مع الحسابات الدائنة والمدينة والأستاذ العام والمخزون. كثيراً ما يطمئن الرعاة الذين وقّعوا ميزانية الترحيل فِرقَهم قائلين: "إنه في الأساس النظام ذاته، لكن في السحابة." لا، ليس كذلك ^[1].

يختفي التنقل القائم على القوائم في GP — حيث كان المستخدمون يعرفون المسار الدقيق لكل شاشة. يعتمد Business Central على نموذج البحث أولاً ومراكز الأدوار. يُمضي المستخدمون المتمرسون الذين اعتادوا التنقل في GP بالذاكرة العضلية أسابيع في إعادة المعايرة. فضلاً عن ذلك، فإن التخصيصات التي اعتمدت عليها فِرقك — تعديلات Dexterity، والمُشغّلات المبنية على SQL، والإضافات الخارجية — لا تُرحَّل. يجب تقييم كل منها على حدة، وإعادة بنائها كامتدادات BC، أو استبدالها بميزات أصلية، أو إيقافها كلياً ^[2].

يتعامل الفريق التقني مع هذا التحوّل بصورة معقولة، لأن ذلك طبيعة عمله. أما موظف الحسابات الذي أجرى الإغلاق الشهري ذاته منذ 2017، فيتعامل معه بصعوبة أكبر بكثير، ولم يُخصَّص في الميزانية ما يُغطّي منحنى تعلّمه.

ما الذي يتغيّر فعلياً على المستخدمين اليوميين

القائمة الصريحة لما يتبدّل على المشغّلين منذ اليوم الأول:

1. التنقل. اختفت شجرة قوائم GP. يعتمد Business Central على مراكز الأدوار — صفحات رئيسية مُخصَّصة — وشريط بحث شامل. المستخدمون الذين لا يجدون الشاشة المطلوبة يتوقفون عن استخدام النظام ويلجؤون إلى حلول بديلة.
2. إنشاء التقارير. أتاحت SmartLists في GP للمستخدمين غير التقنيين استعلامات مرنة وفورية. يستبدل BC هذا بالتقارير المالية وجداول الحسابات وتكامل Power BI. القدرة أكبر، لكن المسار للوصول إليها مختلف ^[3]. إن لم يُعيَّن أحدٌ لتعيين أكثر عشرين SmartList استخداماً إلى مقابلاتها في BC قبل الإطلاق، ستسمع عن ذلك في اليوم الثاني.
3. سير موافقات الاعتماد. كانت الموافقات في GP غير رسمية في الغالب — مكالمة هاتفية، رسالة WhatsApp، مطبوعة بتوقيع المدير. يحتوي BC على سير عمل موافقات منظّمة مدمجة. إن لم تُهيَّأ تلك السلاسل قبل الإطلاق، إما أن ينهار سير العمل أو يتجاوزه المستخدمون ^[1].
4. منطق الترحيل المحاسبي. أتاح GP مرونة أكبر في تأريخ المعاملات المُرحَّلة وتعديلها. BC أكثر صرامة. الفِرق المالية المعتادة على تعديل القيود المُرحَّلة مباشرةً ستجد منطق مسار التدقيق في BC مُرهِقاً حتى تُدرك آليات التصحيح المتاحة.
5. أنماط إدخال البيانات. يختلف نموذج الإدخال الدُفعي في GP عن النموذج المستندي في BC. المستخدمون الذين يُعالجون حجماً كبيراً من المعاملات — موظفو الحسابات الدائنة، ومستلمو المخزون — يحتاجون إلى تدريب صريح على المقابل في BC لكل إجراء يؤدّونه حالياً ^[2].

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

الخمسة أمور التي يجب حسمها قبل التحويل

هذه ليست قرارات تقنية. إنها قرارات عمل لا يستطيع الفريق التقني اتخاذها نيابةً عنك.

1. إعادة تصميم دليل الحسابات. ترحيل GP هو اللحظة المناسبة لإعادة هيكلة دليل الحسابات — لا نقله حرفياً. معظم بيئات GP تحوي حسابات أُضيفت بشكل انتهازي عبر السنين، بمنطق أبعاد وتسميات غير متسقة. نقل تلك البنية إلى BC دون تغيير يعني توارث كل اختصار اتخذه أسلافك. قرّر أي الحسابات تُجمَّع، وأيها يُقسَّم، وكيف تحلّ الأبعاد محل الشرائح، قبل استيراد سجل واحد ^[3].

2. استراتيجية المعاملات المفتوحة. هل تُرحَّل الفواتير المفتوحة وأوامر الشراء المفتوحة وأوامر البيع المفتوحة؟ أم تبدأ بأرصدة افتتاحية نظيفة وتُعيد إدخال الحسابات النشطة يدوياً؟ لا توجد إجابة صحيحة عالمية — يعتمد الأمر على حجم المعاملات وجودة بيانات GP. لكن يجب أن يُحسم القرار، وأن يصدر من القيادة المالية، لا من شريك التنفيذ ^[1].

3. خطة استبدال التخصيصات. اعمل قائمة بكل تخصيص في GP تستخدمه فِرقك. ولكل واحد: هل يستطيع BC تنفيذه أصلاً؟ إن لا، هل ثمة تطبيق BC؟ إن لا، هل يحتاج إلى إعادة بناء؟ إن كان التخصيص موجوداً بسبب حل مؤقت لعملية لم تعد منطقية، أوقفه. هذا التدقيق شاقّ ويجب أن يحدث قبل الإطلاق، لا بعده ^[2].

4. إعادة رسم خريطة التكاملات. كان GP متصلاً بنظام المستودع، والبنك، وكشوف الرواتب، ومنصة التجارة الإلكترونية، أو مزيج من جداول البيانات تعمل وسيطاً. يتصل BC بطريقة مختلفة. تكاملات المخزون بصفة خاصة تحتاج إلى إعادة رسم دقيقة — مقالتنا حول تكامل WMS مع Business Central تتناول نقاط الفشل العملية بالتفصيل. ارسم كل تدفق بيانات على الورق قبل افتراض أن الموصّل سيتولى الأمر.

5. نطاق اختبار قبول المستخدم. اختبار قبول المستخدم ليس "هل يعمل النظام؟" بل هو "هل يستطيع مستخدم حقيقي، في دوره الحقيقي، إنجاز مهامه الحقيقية دون مساعدة؟" حدّد سيناريوهات محددة لكل قسم. نفّذها مع الأشخاص الذين سيستخدمون النظام فعلاً — لا مع مدير المشروع الذي يحلّ محلهم ^[1].

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

أساليب التدريب الفعّالة للفِرق غير التقنية

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

ما يُجدي نفعاً:

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

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

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

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

مبدأ واحد يربط كل هذا: لوحة البيانات ليست قراراً. Business Central يمنحك رؤية أفضل مما أتاحه GP في أي وقت — لكن فقط إذا وثق مشغّلوك بالبيانات التي يُدخلونها. التدريب هو الطريقة التي تكسب بها تلك الثقة.

رأي تارسين: أين ينبغي لمشغّلي الخليج إنفاق ميزانية الترحيل

هذه هي النسخة الصريحة من محادثة الميزانية.

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

أما التكاليف التي تحظى بوزن أقل من اللازم — والتي تُحدد ما إذا كان الترحيل سيُحقق نتائجه فعلاً — فهي: توثيق العمليات، ومعالجة البيانات، والتدريب.

توثيق العمليات قبل الترحيل يعني كتابة طريقة عمل شركتك اليوم بلغة واضحة: من يعتمد ماذا، وما الذي يُطلق أمر الشراء، وكيف تُحسم الفاتورة المتنازع عليها، وماذا يحدث حين تصل شحنة ناقصة. يبدو هذا العمل عبئاً إضافياً. لكنه في الحقيقة الأساس الذي يجعل قرارات تهيئة BC قابلة للحل بدلاً من أن تكون ضرباً من الحدس. إن كانت عملياتك غير رسمية — وفي معظم شركات الخليج، تعمل أجزاء كبيرة من العمليات عبر WhatsApp والمكالمات الهاتفية وسبعة وثلاثين جدول بيانات تعمل بوصفها ERP جماعياً — وثّقها أولاً، ثم هيّئ BC حول النسخ الرسمية منها.

معالجة البيانات غير مُبهجة وهي الخطوة الأكثر تخطياً. تنظيف الموردين المكررين قبل الترحيل يستغرق أسبوعين من العمل. اكتشافهم بعد الترحيل، حين تُعزى فروق المطابقة إلى BC، يستغرق ثلاثة أشهر من الارتباك ^[1]. أنفق الوقت قبل الإطلاق.

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

في مسألة ميزات الذكاء الاصطناعي: قدرات Copilot في BC حقيقية ومتنامية، ومقالتنا حول وكلاء الذكاء الاصطناعي في Dynamics 365 وحدودهم الفعلية تضع توقعات واقعية. لكن التسلسل الصحيح هو: بيانات نظيفة أولاً، مشغّلون مدرَّبون ثانياً، تعزيز بالذكاء الاصطناعي ثالثاً. المشغّلون الذين لا يتنقلون في BC بثقة لن يستفيدوا من اقتراحات الذكاء الاصطناعي المُضافة فوق ارتباكهم.

قبل انطلاق الترحيل، نوصي بمراجعة منهجية للعمليات والجاهزية — النوع ذاته من التقييم الذي ننفّذه عبر تفاعل /Audit — للكشف عن مشكلات جودة البيانات والثغرات في التخصيصات والتبعيات في سير العمل قبل أن تكشف عن نفسها في يوم الإطلاق. الأسئلة ليست مريحة. لكن الإجابة عنها الآن أرخص بكثير من اكتشافها لاحقاً.

تنفيذ ERP يستغرق ستة أشهر. العيش مع تبعاته يمتد ست سنوات. ينبغي أن تعكس نسبة اهتمامك هذا الواقع.