كيف تُهيئ الشركة لاختيار نظام سير العمل/BPM/RPA/ERP/CRM دون الارتهان لمورّد واحد؟

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

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

لماذا ينشأ الارتهان لمورّد واحد منذ البداية

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

الخطوة الأولى: صِف العمليات قبل التحدث إلى الموردين

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

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

الخطوة الثانية: تحقّق مما هو موجود لديك بالفعل

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

الخطوة الثالثة: المتطلبات التي تحمي من الارتهان لمورّد واحد

يُستحسن إدراج هذه المتطلبات في طلب العروض كشروط ملزمة، لا كرغبات:

1. تصدير البيانات وسجلّ القضايا بصيغة مفتوحة وموثّقة، في أي وقت ودون رسوم إضافية.
2. واجهة برمجة تطبيقات (API) موثّقة للتكامل مع أنظمة أخرى، مع حق استخدامها من قبل مقاولين آخرين.
3. عمليات مدوَّنة وفق معيار (BPMN) يمكن تصديرها وإعادة بنائها في مكان آخر.
4. حق إجراء الإعدادات من قِبل فريقكم الخاص أو أي شريك آخر، مع توثيق التغييرات.
5. قواعد الخروج من العقد: فترة انتقالية، ومساعدة في ترحيل البيانات، وتكلفة معروفة مسبقاً.
6. حرية اختيار شريك الصيانة: هل يمكن بعد التنفيذ الانتقال إلى شركة تنفيذ أخرى دون فقدان دعم الجهة المصنّعة.

الأمر نفسه ينطبق على RPA وERP وCRM

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

RPA. السؤال الأول هو: لماذا RPA تحديداً وليس BPM؟ فالروبوت البرمجي يتولى المهام المتكررة التي كان ينجزها الإنسان في الأنظمة القائمة، لكنه لا يُغيّر العملية نفسها؛ أما BPM فينظّم العملية ذاتها. فإذا كان الهدف تخفيف العبء عن الموظفين في نقل البيانات بين الأنظمة يدوياً، فقد يكفي الروبوت. أما إذا كان الهدف إيجاد تدفق عمل جديد وأقصر، فغالباً ما يُكرّس الروبوت التدفق القديم. كما يعتمد الروبوت على واجهات وصيغ الأنظمة الأخرى: فأي تغيير فيها قد يوقفه، لذا يُستحسن معرفة تكلفة صيانة السيناريوهات والاحتفاظ بوصفها خارج أداة الجهة المصنّعة.

ERP. السؤال الجوهري هنا هو: هل يُفترض أن يمنحنا نظام ERP أفضل الممارسات وعمليات جاهزة، أم أن يدعم عملياتنا الخاصة التي تبني ميزتنا التنافسية؟ في الحالة الأولى، يُستحسن الالتزام بمعيار النظام والحدّ من التعديلات، لأن كل تعديل يُصعّب التحديثات وتغيير الشريك. وفي الحالة الثانية، يُثبت أحياناً نظام ERP بسيط، محاط بنظام BPM مرن، فعاليةً أكبر، إذ يتيح تعديل العمليات المميِّزة للشركة دون المساس بالنواة. وفي الحالتين، يجب أن يكون بالإمكان استخراج البيانات المالية والمخزنية وبيانات الموارد البشرية، وكذلك عمليات التكامل مع KSeF والبنوك، بكاملها ومعها سجلّها التاريخي.

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

الخطوة الرابعة: قارِن التكلفة الإجمالية، لا سعر الترخيص

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

الخطوة الخامسة: الاستلام وعقد الصيانة

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

مثال من الممارسة العملية

في مجموعة شركات تابعة لتكتل دولي، كانت الشركة تستخدم نظام ERP مركزياً، وفي الوقت نفسه كانت بحاجة إلى أتمتة العمليات المالية ضمن مجموعة procure-to-pay (الشراء حتى السداد)، وذلك وفق توجيهات الشراء المؤسسية (corporate purchasing guidelines). وكان الإغراء كبيراً للجوء إلى أدوات العمل الجماعي المؤسسية، لكنها تبيّنت باهظة التكلفة نسبياً، ولم تلبِّ متطلبات الاستقلالية ولا سهولة الخروج منها في حال ظهور مشكلات.

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