ما الذي يحتاجه نظام ERP فعلاً — قبل أن تشتري أو تبني واحداً

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

القاعدة الأولى: المستند لا الشاشة

نظام ERP الحقيقي مبني على دورة مستندات، وكل مستند فيها ينشأ من سابقه ويحمل أثره:

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

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

ومن هذه القاعدة تنبع خاصية تُهمَل: الاستلام والصرف الجزئيان. الواقع لا يأتي بالكمية كاملة دائماً، والنظام الذي لا يعرف إلا «مستلَم بالكامل» يُدار من خارجه بجداول جانبية خلال أسابيع.

القيد المزدوج ليس تفصيلاً محاسبياً

كل حركة ذات أثر مالي يجب أن تولّد قيداً متوازناً تلقائياً: البيع، والشراء، والاستلام، والصرف، وفروق التكلفة، والاستهلاك. لا «شاشة قيود» منفصلة يُدخل فيها المحاسب ما فعلته بقيّة الأقسام.

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

المخزون: أين يفشل معظم الأنظمة

ثلاثة أسئلة يجب أن يجيبها النظام بوضوح قبل أن تعتمده:

• كيف تُحتسب التكلفة؟ متوسط مرجّح، أم الوارد أولاً صادر أولاً، أم تكلفة محدّدة لكل قطعة؟ الاختيار يغيّر تكلفة البضاعة المباعة ويغيّر الربح المعلن. ولا توجد إجابة صحيحة لكل نشاط، لكن توجد إجابة يجب أن تكون معلومة ومطبَّقة باتّساق.
• هل الكمية مربوطة بموقع؟ «عندي ٤٠ قطعة» جواب ناقص إن كان لديك مستودعان وفرعان. الرصيد يجب أن يكون لكل صنف في كل موقع.
• هل يُسمح بالرصيد السالب؟ منعه يبدو صواباً حتى يوقف عملية بيع لأن الإدخال تأخّر. اجعله قراراً معلناً قابلاً للضبط، لا مفاجأة تُكتشف في ساعة الذروة.

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

الفروع والصلاحيات

لحظة تفتح المنشأة فرعاً ثانياً يتحوّل كل شيء. سؤالان يجب أن يكونا مبنيّين في الأساس لا مضافين لاحقاً: هل يرى مستخدم الفرع بيانات الفرع الآخر؟ وهل الأرصدة والتقارير مفصولة ومجمّعة في آنٍ معاً؟

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

سجلّ التدقيق والاعتمادات

سجلّ التدقيق ليس سجلّ دخول. هو: من غيّر أي حقل، في أي مستند، متى، وما القيمة قبل وبعد. اطلب رؤيته في العرض التجريبي على مستند حقيقي؛ كثير من الأنظمة تدّعيه وتسجّل «تم التعديل» بلا تفاصيل.

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

الفوترة الإلكترونية

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

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

وكذلك ضريبة القيمة المضافة نفسها: نسبتها الأساسية ١٥٪، ومعالجتها في النظام يجب أن تسمح بأصناف بنسب مختلفة وبمعاملات معفاة أو صفرية — لا نسبة واحدة مكتوبة في الكود.

سؤالان أخيران قبل التوقيع

1. بياناتي — كيف أُخرجها؟ اطلب تصديراً كاملاً بصيغة مفتوحة قبل أن تدخل بياناتك. النظام الذي يصعب الخروج منه يكلّفك لاحقاً أضعاف ما وفّره.
2. ماذا يحدث عند تكرار الطلب؟ ضغطة مزدوجة على «ترحيل»، أو نقرة على «تحديث» بعد الحفظ، يجب ألّا تنتج فاتورةً مكرّرة أو قيداً مكرّراً. اطلب تجربتها أمامك — وهي من أكثر العلل شيوعاً في الأنظمة المبنيّة على عجل.

وأين يبدأ العمل عملياً

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