البناء مقابل الشراء

الإجابة الصحيحة: A. The app is a strategic differentiator that no product meets, and the organization has skilled developers and can support the app long term

✅ لماذا هذه الإجابة

البناء الداخلي مناسب عندما تجتمع ثلاثة شروط:

• الحل ميزة استراتيجية تميز المنظمة، ولا يوجد منتج في السوق يلبيه.
• توجد قدرات داخلية مؤهلة للتطوير.
• توجد قدرة على الدعم والصيانة طويلة الأمد، لا البناء فقط.

❌ لماذا البدائل الأخرى خاطئة

• (B): وجود منتجات ناضجة تلبي أغلب الحاجة يرجح الشراء، مع إعدادات بسيطة (Configuration).
• (C): دون مطورين يصبح البناء مخاطرة كبيرة أو اعتمادًا كاملًا على متعاقدين.
• (D): الموعد القصير يرجح الشراء؛ فالبناء يحتاج وقتًا أطول عادةً.

💡 المفهوم الأساسي

كثيرًا ما تُحسب تكلفة البناء الأولى وتُنسى تكلفة الصيانة والتحديث والأمن طوال العمر. ولذلك تُقارن التكلفة الإجمالية للملكية (TCO: Total Cost of Ownership) للخيارين. ويوجد خيار وسط: شراء منصة وإعدادها (Configuration) أو توسيعها، أو البناء فوق واجهات برمجة التطبيقات (API: Application Programming Interface) المعيارية.

وفي الامتحان: «ميزة استراتيجية لا يلبيها منتج + مطورون مؤهلون + قدرة على الدعم الطويل» = البناء (Build). و«منتجات ناضجة تلبي معظم الحاجة» أو «موعد قصير» أو «لا مطورين» = الشراء (Buy).

🔗 معلومات وأسئلة مرتبطة

• الإعداد أم التعديل: الإعداد (Configuration) يستخدم أدوات المورد نفسها، أما التعديل (Customization) فيغير الكود المصدري للمنتج.
  سؤال تدريبي: أراد المستشفى ميزة خاصة في منتج مشترى، فعدّل كوده المصدري بدل استخدام أدوات الإعداد. ما الخطر الأكبر لاحقًا؟ ← صعوبة الترقيات؛ فكل إصدار جديد من المورد قد يلغي التعديل أو يتعارض معه، ويحتاج إعادة اختبار وبناء.
• تطبيقات فوق السجل بمعيار مفتوح: طريق وسط بين البناء الكامل والشراء. فنهج SMART on FHIR (Substitutable Medical Applications, Reusable Technologies on Fast Healthcare Interoperability Resources) يتيح لتطبيق صغير أن يعمل داخل السجل الصحي الإلكتروني (EHR: Electronic Health Record)، ويقرأ بياناته عبر معيار FHIR المفتوح، فيمكن تشغيله مع أكثر من نظام سجل.
  سؤال تدريبي: يريد مستشفى حاسبة جرعات خاصة به تظهر داخل شاشة السجل، وقد يغيّر مورد السجل بعد ثلاث سنوات. أيهما أسلم: تعديل الكود المصدري للسجل، أم بناء تطبيق SMART on FHIR؟ ← تطبيق SMART on FHIR؛ فهو يتصل بالسجل عبر واجهة معيارية ولا يغيّر كود المنتج، فيقل كثيرًا احتمال أن تعطله ترقيات المورد، ويمكن نقله إلى سجل آخر يدعم المعيار.
• استمرارية التطبيق المبني داخليًا: البناء الداخلي لا ينتهي بالتسليم؛ فالتطبيق يحتاج من يفهم كوده بعد سنوات. والاعتماد في ذلك على مطور واحد يُسمى خطر الاعتماد على شخص واحد (Key Person Risk).
  سؤال تدريبي: تطبيق بناه مطور واحد ولم يوثقه، وهو يعمل جيدًا، والمطور ما زال في المنظمة. يقول المدير: لا يوجد ما يحتاج معالجة الآن. هل هذا صحيح؟ ← لا؛ فخطر الاعتماد على شخص واحد قائم الآن، ومعالجته بعد مغادرة المطور متأخرة. ويُقلل بالتوثيق، ومراجعة الكود، وتوزيع المعرفة على أكثر من شخص.
• تقييم الشراء: يمر عادةً بطلب عروض (RFP: Request for Proposal)، وعروض توضيحية بسيناريوهات حقيقية، والتواصل مع عملاء حاليين للمورد (Reference Checks).
• الاعتماد على المورد (Vendor Lock-in): الشراء يربط المنظمة بخارطة طريق المورد وأسعاره، لذلك تُراجع شروط الخروج وإعادة البيانات قبل التوقيع.
• نهج الأفضل في فئته: سؤال مرتبط في البنك الكامل.
• التكلفة الغارقة: التكلفة الغارقة وتكلفة الفرصة البديلة.
• التكلفة الإجمالية للملكية: «التكلفة الإجمالية للملكية (TCO)» (في البنك الكامل).