الحلول

استشارات ERP وتطويره

تحليل العمليات والاختيار والتطبيق والتطوير وترحيل البيانات والتكامل ضمن منظومات ERP متعدّدة. وتطوير النظام الذي تشغّلونه حاليًا أحد الخيارات.

احجزوا تحليل احتياجات ERP ↗
استشارات ERP وتطويره
منظومات ERP التي نعمل ضمنها
  • CANIAS
  • Ainos ERP
  • SAP
  • Kovan ERP
  • Oracle

تُحدَّد المنظومة التي يجري فيها العمل حسب بنيتكم القائمة وما يحتاجه المشروع.

يقودنا التحليل إلى ثلاثة مسارات

01

تطوير نظام ERP القائم

حيث تكون الوظائف الأساسية كافية، تُستكمل العمليات الناقصة بالتطوير أو التكامل أو تطبيقات محيطة.

02

تحوّل ERP

حيث لا يستطيع النظام الحالي تلبية الحاجة وظيفيًا أو تقنيًا أو تشغيليًا، تُوزن البدائل أمام صورة مقيسة.

03

معمارية هجينة

يُحافَظ على نواة ERP؛ وتُحلّ العمليات المتباعدة حولها بتطبيقات B2B أو WMS أو نقاط بيع أو تطبيقات محمولة أو مخصّصة.

نحلّل الحاجة أولًا، لا نظام ERP

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

لذلك ليس سؤالنا الأول عند بدء أيّ مشروع «أيّ نظام ERP ينبغي أن تشتروا؟». بل نبحث أولًا عن إجابات هذه الأسئلة:

  • أيّ العمليات تعمل بصورة سليمة اليوم؟
  • أيّ العمليات تُدار يدويًا خارج نظام ERP؟
  • أيّ البيانات لا يمكن الوثوق بها، وما مصدر ذلك؟
  • عند أيّ نقطة يخرج المستخدمون من النظام وينتقلون إلى Excel؟
  • أيّ التقارير تُعدّ بدمج بيانات من أنظمة مختلفة؟
  • أيّ عمليات التكامل ناقصة أو غير قابلة للمتابعة؟
  • هل بُلغ فعلًا الحدّ التقني أو الوظيفي لنظام ERP الحالي؟

وينتهي هذا التحليل عادةً إلى واحد من ثلاثة مسارات.

تطوير نظام ERP الحالي

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

تحوّل ERP

إذا كان النظام الحالي لا يلبّي حاجة المنشأة وظيفيًا أو تقنيًا أو تشغيليًا، تُدرَس بدائل ERP الجديدة. وينبغي أن يستند هذا القرار إلى جدول مقيس، لا إلى شكوى واحدة.

المعمارية الهجينة

يُحافَظ على نواة ERP بينما تُوضَع العمليات الخاصّة بالمنشأة حول النظام عبر تطبيقات B2B أو WMS أو نقاط البيع أو تطبيقات الهواتف أو تطبيقات مخصّصة. تبقى النواة قياسية، وتُحلّ العملية المختلفة في موضعها.

النتيجة الصحيحة عندنا ليست دائمًا «غيّروا نظام ERP». فإذا أظهر التحليل أنّ النظام الحالي قابل للتطوير، قلنا ذلك صراحةً.

أنغيّر نظام ERP أم نطوّر النظام الحالي؟

تغيير ERP قرار عالي الأثر: تتغيّر البيانات والعمليات وعادات المستخدمين وعمليات التكامل كلّها في وقت واحد. ولا بدّ قبل الانتقال إلى نظام جديد من قياس ما إذا كان نظام ERP الحالي قد بلغ حدّه فعلًا.

قد يكون تطوير النظام الحالي منطقيًا:

  • إذا كانت عمليات المالية والمخزون والطلبات الأساسية تعمل بصورة سليمة،
  • إذا كانت المشكلة متركّزة في عدد محدود من العمليات،
  • إذا أمكن حلّ نواقص التكامل من خارج نظام ERP،
  • إذا كان النظام الحالي مستدامًا من الناحية التقنية.

وقد يصبح التحوّل إلى ERP جديد خيارًا أقوى:

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

ونشرح تفصيل إطار القرار في دليل اختيار ERP.

نطاق خدماتنا

تحليل عمليات ERP وتحليل الفجوة

نحلّل العمليات القائمة على مستوى كلّ قسم؛ ونفصل بين المجالات التي تُلبّى بوظيفة قياسية، وتلك التي تحتاج إلى إعداد، وتلك التي تحتاج إلى تطوير، وتلك التي تُحلّ بالتكامل.

والمخرَج ليس عرضًا تقديميًا فحسب: بل عمل يصلح أساسًا لنطاق المشروع ومعايير القبول، ويمكن أن يُدرج ملحقًا بالعقد.

استشارات اختيار ERP

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

والعناوين التي تُدرس معًا في التقييم:

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

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

التنفيذ والتطوير في منظومات ERP المتعدّدة

لا نعدّ علامة ERP واحدة صحيحة لكلّ منشأة. فنحن ننفّذ أعمال تكييف العمليات والتكامل والتقارير وسير العمل وتحويل البيانات والتطوير في منظومات ERP مختلفة بحسب حاجة المشروع، منها CANIAS وAinos ERP وSAP وKovan ERP وOracle.

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

ونقارن في مقال البدائل في منظومة ERP أيّ المنتجات أجدر بالدفاع عنه في أيّ ظرف.

ERP التصنيع وإدارة التكاليف

الغاية في مشاريع ERP التصنيعية ليست فتح أمر إنتاج فحسب؛ بل يجب أن يكون الإنتاج المخطَّط وبيانات الاستهلاك والعمليات الفعلية قابلَين للمتابعة على النموذج نفسه.

ونمذج داخل نظام ERP بحسب الحاجة مكوّنات شجرة المنتج أو الوصفة، والمسار والعملية، وبنية مركز العمل أو المورد، واستهلاك المواد، وأزمنة العمالة والآلات، والهدر وإعادة التشغيل، والعمليات المسندة إلى الغير، وتتبّع اللوط أو الرقم التسلسلي، والطاقة الإنتاجية، وMRP، والجودة، وتكلفة الإنتاج، وذلك بحسب نمط التصنيع في المنشأة. ولا تحتاج كلّ منشأة إلى هذه المكوّنات كلّها؛ فالمسار البديل أو العملية المسندة إلى الغير لا تُبنى إلّا إذا كانت مستخدمة فعلًا.

ولا نفرض أسلوبًا واحدًا في نموذج التكلفة. فالتكلفة المعيارية، والتكلفة الفعلية، وتكاليف النشاط والآلة والعمالة، وأسلوب توزيع المصاريف العامّة، كلّها تُصمَّم معًا بحسب النموذج المحاسبي والإنتاجي للمنشأة. والتفصيل في دليل ERP لشركات التصنيع.

ترحيل بيانات ERP

لا يتحدّد نطاق ترحيل البيانات بسؤال «كم سنة من البيانات ستُنقل؟». بل نتناول البيانات المنقولة في ثلاث فئات:

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

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

عمليات تكامل ERP

لا يعمل نظام ERP وحده في معظم المنشآت. فقد يلزم تدفّق بيانات بين البنك، والفاتورة وإشعار التسليم الإلكترونيَّين، وبوابة الموزعين B2B، ونقاط البيع بالتجزئة، وWMS، وقنوات التجارة الإلكترونية والأسواق، ونظام إدارة علاقات العملاء، والمبيعات الميدانية، وتسجيل الحضور والانصراف، وMES، وآلات الإنتاج، والموازين، وخدمات الأطراف الثالثة.

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

شركات المجموعة والتوحيد المالي

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

وقد لا تكفي في بعض البنى وظائف ERP نفسها للتوحيد المالي أو لتقارير الإدارة؛ وفي هذه الحالة نوضّح في بداية المشروع صراحةً أنّ طبقة تقارير إضافية قد تكون لازمة.

تحسين نظام ERP الحالي

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

لذلك نقيّم النظام الحالي تقنيًا ووظيفيًا قبل اتخاذ قرار بنظام ERP جديد. وإذا كان الاستثمار القائم قابلًا للتطوير، أوصينا بذلك صراحةً.

منهجنا في مشاريع ERP

  1. الاستكشاف وتحليل العمليات. تُحدَّد مسارات العمل والمشكلات الحرجة ومصادر البيانات وعمليات التكامل.
  2. تحليل الفجوة وتصميم الحلّ. تُفصل مجالات الوظيفة القياسية والإعداد والتطوير والتكامل.
  3. النطاق ومعايير القبول. تُعرَّف المخرجات بمعايير قابلة للاختبار، لا بعبارات مثل «تمّ تشغيل الوحدة».
  4. الإعداد والتطوير. يُحافَظ قدر الإمكان على القدرات القياسية لنظام ERP؛ وتُوثَّق التخصيصات اللازمة.
  5. التكامل وترحيل البيانات. تُعرَّف مصادر البيانات ومجاميع التحقّق وسيناريوهات الخطأ وخطوات المطابقة.
  6. الاختبار واختبار قبول المستخدم. تُختبر سيناريوهات عمل حقيقية مع المستخدمين الرئيسيين.
  7. استراتيجية الانتقال. يُختار بحسب خطر المشروع الأسلوب المناسب من بين التجربة الاسترشادية أو الانتقال على مراحل أو التشغيل المتوازي أو التحويل المُحكَم.
  8. الإطلاق والدعم المكثّف. يُنتقَل إلى التشغيل الفعلي بعد استكمال الضوابط الحرجة؛ وتُطبَّق مراقبة ودعم مكثّفان في الفترة الأولى.

أين نستخدم الذكاء الاصطناعي في ERP؟

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

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

كيف تُقيَّم تكلفة ERP؟

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

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

ونشرح الحساب بندًا بندًا في مقال كيف تُحسب تكلفة ERP؛ ويمكنكم استخدام أداة التقييم الأوّلي لاستثمار ERP والتكلفة الإجمالية لاستخراج درجة التعقيد وقائمة البنود بحسب نطاقكم.

لماذا FAB Teknoloji في مشروع ERP؟

لا نبدأ من منظور منتج واحد

نبدأ التقييم من واقع عمليات المنشأة وبياناتها، لا من مقارنة المنتجات.

ننفّذ الاستشارات والتطوير معًا

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

نطوّر كذلك الأنظمة المحيطة بـERP

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

نتناول جانب التصنيع والتكامل بعمق تقني

لا نتعامل مع ERP باعتباره تطبيق مالية ومحاسبة فحسب؛ بل يقع نموذج التصنيع وجمع البيانات ومعمارية التكامل في قلب المشروع.

نرى الحفاظ على استثماركم القائم خيارًا أيضًا

إذا لم يكن نظام ERP جديد لازمًا، فإنّ تطوير النظام الحالي أحد خيارات المشروع، ونقول ذلك ولو كلّفنا خسارة المشروع.

نحرص على ألّا نُنشئ تبعية

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

في أيّ القطاعات نعمل؟

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

أسئلة اطلبوا إجابتها كتابةً قبل العرض التوضيحي والعقد

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

وتجدون تقييم شركة الاستشارات كاملًا في مقال كيف تُختار شركة استشارات ERP.

الأسئلة الشائعة

مع أيّ منتجات ERP تعملون؟

لسنا مرتبطين بمنتج ERP واحد. فنحن ننفّذ مشاريع استشارات وتطوير وتكامل وتحوّل في منظومات ERP مختلفة، منها CANIAS وAinos ERP وSAP وKovan ERP وOracle. ويُحدَّد نطاق المشروع والأسلوب المستخدم بحسب النظام الحالي للمنشأة واحتياجاتها.

هل يمكننا العمل معكم دون تغيير نظام ERP لدينا؟

نعم. فاستشارات ERP لا تعني تركيب نظام جديد فحسب. إذ ننفّذ كذلك أعمال تحليل العمليات والتكامل والتطوير والتقارير ونموذج البيانات وتحسين الأداء على نظام ERP القائم.

كيف تقرّرون أنّ نظام ERP جديدًا صار لازمًا؟

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

كم يستغرق مشروع ERP؟

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

هل يجب نقل كامل التاريخ في ترحيل بيانات ERP؟

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

هل التشغيل المتوازي شرط في مشروع ERP؟

لا. يُحدَّد أسلوب الانتقال بحسب خطر المشروع. ويمكن استخدام الأنسب من بين التشغيل المتوازي أو التجربة الاسترشادية أو الانتقال على مراحل أو التحويل المُحكَم.

هل التطوير الخاصّ في ERP أمر سيّئ؟

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

ما أهمّ معيار في اختيار ERP؟

لا يوجد معيار واحد. فالتوافق الوظيفي، والمعمارية التقنية، والتكامل، والتكلفة الإجمالية، ومنظومة التنفيذ، والاستدامة، ينبغي تقييمها معًا.

كيف يُدار خطر فقدان البيانات عند الإطلاق؟

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

من يقدّم تدريب المستخدمين؟

نقدّم تدريبًا قائمًا على الأدوار: كلّ دور يتعلّم شاشاته وحدها. كما نؤهّل بنموذج المستخدم الرئيسي أشخاصًا من داخل المؤسسة يحملون النظام لاحقًا. وهذا مهمّ حتى لا تبقى المؤسسة معتمدة على الاستشاري في كلّ تغيير صغير بعد ذلك.

المنهج في رسمين

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

لنراجع منظومة ERP لديكم معًا

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

اتصلوا بي