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