جواب سؤال التخصيص ليس «هل يمكن فعله» بل «ماذا يحدث عند الترقية». ففي CANIAS ERP يجري التطوير على منصّة TROIA التي تأتي مع المنتج. وهذه المرونة ميزة حقيقية؛ لكنّ تحوّلها إلى ميزة يتوقّف على كيفية إجراء التخصيص وكيفية توثيقه. ويتناول هذا المقال ذلك الانضباط.
ما TROIA؟
بحسب تعريف المنتِج، TROIA لغة برمجة من الجيل الرابع كائنية التوجّه؛ وتُقدَّم معها بيئة تطوير متكاملة ومترجِم ومفسِّر. ويذكر المنتِج كذلك أنّ العملاء يستطيعون الوصول إلى الشيفرة المصدرية، وأنّه لا تلزم إعادة الترجمة أثناء التطوير، وأنّ التطبيقات القائمة يمكن تعديلها من دون إعادة تشغيل النظام. وأدوات تصحيح الأخطاء والمراقبة جزء من المنصّة.
ومعنى ذلك عمليًا: لا يلزمكم بناء حزمة تطوير منفصلة لتخصيص الشاشات والتقارير وقواعد العمل. وهذا يقلّل عبء التهيئة التقنية في المشروع.
البنية المتقاطعة: التخصيص دون تغيير الكائن القياسي
يقوم نهج التخصيص الذي يصفه المنتِج على إمكان استخدام صنف خاصّ بالعميل بدل صنف قياسي. وأهمّية هذا التمييز:
- لا يُمَسّ الكائن القياسي. فحين يحدّث المنتِج الكائن القياسي، يبقى سطح التعارض ضيّقًا.
- يبقى للتخصيص هويته الخاصّة. فيمكن رؤية ما تغيّر بمقارنته بالقياسي.
- يمكن تحديد المجموعة الواجب إعادة اختبارها عند الترقية. فبدل «لنختبر كلّ شيء»، تحدّد قائمة الكائنات المَمسوسة نطاقَ الاختبار.
ويقابل هذا النهج تخصيصٌ يغيّر الكائن القياسي مباشرةً. يبدو أسرع على المدى القصير؛ لكنّه يُنتج أغلى بند عند ترقية الإصدار.
ثمن المرونة: دَين التخصيص
مجيء منصّة التطوير مع المنتج يجعل جواب «نعم، يمكن» أسهل. وكلّ جواب أسهل يوسّع النطاق قليلًا. والصورة التي نراها أكثر من غيرها هي: ثلاثون تخصيصًا بدت صغيرة أثناء المشروع تصير بعد ثلاث سنوات الحملَ الذي يقفل الترقية.
لذلك نعيد كلّ طلب تطوير أولًا إلى جدول تحليل الفجوة: هل يمكن تلبية هذه الحاجة بوظيفة قياسية أو بإعداد أو بتكامل؟ فإن تعذّر، أُجري التطوير — لكن يُوثَّق أسلوبه وأثره في الترقية. ونشرح كيفية بناء هذا التقسيم في دليل كيفية اختيار ERP.
ما يجب تسجيله في كلّ تخصيص
- ما الذي تغيّر؟ شاشة أو تقرير أو قاعدة عمل أو طرف تكامل.
- لماذا تغيّر؟ حاجة العمل التي أنشأت الطلب والوحدة التي قدّمته.
- أيّ كائن قياسي مُسّ؟ وإن لم يُمَسّ أيّ كائن، كُتب ذلك أيضًا.
- ما الذي سيُختبَر عند الترقية؟ اسم مسار العمل الذي ينتمي إليه التخصيص.
- من نفّذه ومتى؟ هذا السطر وحده يوفّر وقتًا كبيرًا عند التسليم.
هذه السطور الخمسة هي الوثيقة الوحيدة التي تزداد قيمتها كلّما ازداد عدد التخصيصات. وبدونها، لا يملك أحد بعد ثلاث سنوات جواب سؤال «لماذا هذه الشاشة هكذا».
ثلاثة أرقام تُقاس قبل الترقية
- عدد الشاشات والتقارير المخصَّصة. يُظهر حجم النطاق.
- عدد التخصيصات التي تمسّ كائنات قياسية. يُظهر موضع تركّز الخطر.
- عدد مسارات العمل الواجب إعادة اختبارها بعد الترقية. وهو الرقم الذي يحدّد مدّة مشروع الترقية.
فإن لم تُتابَع هذه الثلاثة، تعذّر تقدير مدّة الترقية؛ والترقية غير القابلة للتقدير تُؤجَّل، والتأجيل يكبّر الدَّين.
قابلية التسلّم
الغرض الثاني من انضباط التخصيص هو استقلالية الفريق. فحين تُعرَّف في العقد شروطُ الوصول إلى الشيفرة المصدرية والتوثيق وخطوات تهيئة البيئة، أمكن لفريق آخر تسلّم المشروع. ونسرد العناوين التي ينبغي كتابة هذه الشروط تحتها في مقال كيف تُختار شركة استشارات ERP.
ونتناول بنية طبقات المنتج ومجموعات وحداته في مقال ما هو CANIAS ERP.
الأسئلة الشائعة
هل البقاء ضمن القياسي أفضل دائمًا من التخصيص؟
لا. ففي العمليات التي تحقّق قيمة فعلية وتحمل ميزة تنافسية يكون التخصيص لازمًا. والمشكلة ليست التخصيص نفسه، بل التخصيص غير الموثَّق والمجهول الأثر.
كم مرّة ينبغي إجراء الترقية؟
تحدّد الدوريةَ رزنامةُ إصدارات المنتج ومدى تحمّلكم للمخاطر معًا. والحاسم هو ألّا تُؤجَّل الترقيات وتتراكم: ففي تركيب متأخّر بإصدارين، تبلغ الترقية حجم مشروع مستقلّ.
من ينبغي أن يُجري التخصيصات: الفريق الداخلي أم الاستشاري؟
كلاهما ممكن؛ والحاسم أن يكون الأسلوب واحدًا. وتأهيل مستخدم رئيسي داخل المؤسسة يستطيع تعديل التقارير والشاشات يخفض تكلفة الاستشارات في السنوات التالية.
هل يصعّب الوصول إلى الشيفرة المصدرية الترقيةَ؟
الوصول بذاته لا يصعّبها. الذي يصعّبها هو استخدام ذلك الوصول لتغيير الكائنات القياسية مباشرةً. فالتخصيص المنفَّذ بأسلوب مدعوم يبقى قابلًا للنقل بصرف النظر عن الوصول.