- تكلفة تطوير نظام إدارة عيادات من الصفر لا تنتهي عند الإطلاق. أكبر بنودها في السنوات التالية: فريق دائم للصيانة، ومواكبة تحديثات نفيس والفوترة الإلكترونية، والأمن، والاستضافة.
- قِس التكلفة بوحدة محايدة: الشهر-فرد، أي تكلفة موظف تقني واحد لشهر بكل أعبائه. في مثالنا التوضيحي يحتاج البناء نحو 318 شهرًا-فردًا على خمس سنوات، قبل الاستضافة واختبارات الأمن.
- المنصة مع التخصيص تكون أوفر ما دام الاشتراك السنوي أقل من تكلفة نحو 55 شهرًا-فردًا في السنة في المثال نفسه، أي أقل من كلفة أربعة موظفين تقنيين ونصف تقريبًا. احسب الحد نفسه بأرقامك.
- الفرق ليس ماليًا فقط: البناء يؤخر التشغيل سنة أو أكثر، ويجعل المنشأة معتمدة على أفراد بأعينهم.
- البناء منطقي فعلًا في حالات قليلة: حين تكون البرمجيات جزءًا من نموذج عملك، أو حين لا تغطي أي منصة جوهر متطلباتك حتى بعد التخصيص، مع قدرة على تمويل فريق دائم.
هذه المقالة للمدير التنفيذي أو صاحب القرار الذي يسأل: هل نبني نظامنا بأنفسنا أم نشترك في منصة ونخصصها؟ ستجد بنود تكلفة البناء كاملة، وجدول مقارنة على خمس سنوات بافتراضات معلنة، وطريقة حساب نقطة التعادل بأرقامك، وشجرة قرار تحدد متى يكون البناء هو الخيار الصحيح.
الخيارات الحقيقية ثلاثة لا اثنان
السؤال يُطرح عادة كأنه «جاهز أم مخصص»، لكن على الطاولة ثلاثة مسارات تختلف في التكلفة والمخاطر:
| المسار | ما يعنيه | من يتحمل الصيانة والتحديث | أين يناسب |
|---|---|---|---|
| البناء من الصفر | فريق داخلي أو شركة برمجة تبني نظامًا خاصًا بكم من البداية | المنشأة، بفريقها أو بعقد صيانة دائم | حالات محددة تشرحها شجرة القرار أدناه |
| منصة جاهزة بالإعدادات | نظام قائم يُضبط على خدماتكم وأسعاركم ونماذجكم دون برمجة | مورد المنصة ضمن الاشتراك | أغلب العيادات والمراكز ذات الإجراءات المعتادة |
| منصة مع تخصيص | الإعدادات أولًا، ثم تطوير مخصص لما لا تغطيه، يُبنى امتدادًا للمنصة | المورد للمنصة، والتخصيص حسب العقد | منشآت لها متطلبات خاصة حقيقية في جزء من عملها |
الفرق بين الإعدادات والتخصيص والتطوير الخاص، وأمثلة كل درجة، موضوع مقالة برنامج عيادات جاهز أم نظام مخصص. وتلخص صفحة الطرق الثلاث للحصول على نظام يناسب منشأتك مزايا كل طريق. هنا نركز على الحساب: كم يكلف كل مسار على خمس سنوات، ومتى يتعادلان.
بنود تكلفة البناء من الصفر، بما فيها ما لا يظهر في عرض شركة البرمجة
عرض شركة البرمجة يغطي عادة بناء النسخة الأولى. أما تكلفة الملكية فتشمل ثمانية بنود:
1. فريق البناء
نظام يغطي المواعيد والملف الطبي والفوترة والتأمين والمخزون والتقارير والصلاحيات يحتاج فريقًا متعدد الأدوار، لا مبرمجًا أو اثنين:
- مالك منتج أو محلل أعمال بخبرة في التشغيل الطبي: يكتب المتطلبات ويقرر الأولويات. غيابه أكثر ما يطيل المشاريع الطبية.
- مطورو الخلفية والواجهات: للمنطق والبيانات والشاشات، وتطبيق للمريض إن كان مطلوبًا.
- مختص جودة واختبار: لكل تعديل، لأن خطأ في حساب حصة المريض أو صرف دواء ليس خطأ شكليًا.
- مهندس بنية وأمن: للاستضافة والنسخ الاحتياطي والتعافي والصلاحيات والتشفير.
- مصمم تجربة استخدام: لأن الطبيب بين مريضين والاستقبال في ساعة الذروة لا يحتملان شاشة بطيئة.
2. المدة حتى أول تشغيل
مدة البناء ليست تكلفة الفريق فقط. كل شهر قبل التشغيل هو شهر تبقى فيه المنشأة على نظامها القديم أو على الورق، بكل ما يتسرب فيه. وتأخر المشاريع البرمجية عن جدولها شائع بما يكفي ليُحسب في السيناريو المتحفظ.
3. الربط مع نفيس
تمر معاملات التأمين من أهلية وموافقات ومطالبات وتسويات عبر منصة نفيس، التي يعتمد دليل تنفيذها المنشور على بوابة نفيس معيار HL7 FHIR بالإصدار R4. بناء هذا الربط يعني تنفيذ عدة أنواع من المعاملات والردود المؤجلة ومجموعات الرموز، ثم اجتياز متطلبات الانضمام لدى المنصة، ثم مواكبة كل تحديث للمواصفات بعد ذلك. ويشرح ما يجب أن يفعله النظام في كل معاملة مقال الربط مع نفيس في نظام العيادة.
4. الفوترة الإلكترونية
تشترط الإرشادات التفصيلية للفوترة الإلكترونية من هيئة الزكاة والضريبة والجمارك في مرحلة الربط إصدار الفاتورة بصيغة XML أو PDF/A-3 تتضمن XML، وختمًا تشفيريًا، وتسجيل وحدات إصدار الفواتير لدى منصة «فاتورة» للحصول على معرّفات الختم، والتكامل معها عبر واجهات برمجية تحددها الهيئة. هذا مشروع قائم بذاته داخل مشروع البناء، ويتكرر عند أي تحديث في المتطلبات.
5. الأمن وحماية البيانات
يصنف نظام حماية البيانات الشخصية البيانات الصحية ضمن البيانات الحساسة. في البناء الذاتي تتحمل المنشأة تصميم الصلاحيات وسجل التدقيق والتشفير والنسخ والاستعادة، واختبارات الاختراق الدورية من طرف خارجي، والاستجابة للحوادث. هذه ليست ميزة تُبنى مرة، بل عمل مستمر.
6. الاستضافة والبنية
خوادم أو سحابة، وبيئة اختبار منفصلة عن الإنتاج، ونسخ احتياطي خارج الموقع، ومراقبة على مدار الساعة، وتراخيص قواعد بيانات وأدوات.
7. الصيانة والتطوير المستمر
بعد الإطلاق لا يختفي الفريق. يبقى جزء منه لإصلاح الأخطاء، وطلبات الأقسام الجديدة، وتحديثات الأنظمة المرتبطة، وتحديث المكتبات البرمجية التي تتقادم. النظام الذي يتوقف تطويره يبدأ في التقادم خلال سنوات قليلة.
8. مخاطر الاعتماد على أفراد
حين يعرف مطور أو اثنان كيف بُني النظام، يصبح رحيلهما خطرًا تشغيليًا. التوثيق والاختبارات الآلية وتداخل المعرفة داخل الفريق تخفف هذا الخطر، لكنها تكلف وقتًا يُحسب في الفريق نفسه.
مقارنة على خمس سنوات بوحدة «الشهر-فرد»
لكي تكون المقارنة صالحة لأي سوق وأي وقت، نحسب بوحدة الشهر-فرد: تكلفة موظف تقني واحد لشهر واحد، شاملة الراتب والبدلات والتأمين والاستقدام والمعدات. ضع قيمتها من واقع منشأتك، ولنرمز لها بالحرف (ت). والاشتراك السنوي للمنصة نرمز له بالحرف (س).
| البند | البناء من الصفر | المنصة مع التخصيص |
|---|---|---|
| بناء النسخة الأولى | 8.5 أفراد × 12 شهرًا = 102ت | لا يوجد |
| التنفيذ والإعداد والترحيل والتدريب | ضمن فريق البناء | ما يعادل 8ت (من عرض المورد) |
| التطوير المخصص للمتطلبات الخاصة | ضمن فريق البناء | 6ت (بتقدير مكتوب قبل البدء) |
| الصيانة والتطوير المستمر | 4 أفراد × 48 شهرًا = 192ت | ضمن الاشتراك |
| إدارة المنتج أو مدير النظام الداخلي | 0.5 فرد × 48 شهرًا = 24ت | 0.5 فرد × 60 شهرًا = 30ت |
| تحديثات نفيس والفوترة الإلكترونية | ضمن فريق الصيانة | ضمن الاشتراك |
| الاستضافة والنسخ والمراقبة | مبلغ سنوي إضافي × 5 | ضمن الاشتراك في النشر السحابي |
| اختبارات الاختراق والتدقيق الأمني | مبلغ سنوي إضافي × 5 | التزامات المورد، وتدقيقكم حسب سياستكم |
| الاشتراك | لا يوجد | 5 × س |
| المجموع القابل للمقارنة | 318ت + الاستضافة + الأمن | 44ت + 5س |
لاحظ أن الجدول متحيز لصالح البناء عمدًا: أغفلنا الاستضافة واختبارات الأمن في الحساب، وافترضنا أن المشروع لا يتأخر. إن صمدت المنصة في هذه المقارنة، فهي أوضح في الواقع.
نقطة التعادل: متى يصبح البناء أرخص؟
يصبح البناء أرخص على خمس سنوات فقط إذا كان مجموع اشتراكات المنصة أكبر من الفرق بين المسارين:
- احسب الفرق بالشهر-فرد
318ت − 44ت = 274ت.
المالية - اقسمه على سنوات المقارنة
274ت ÷ 5 = 54.8ت في السنة. هذا هو الحد الأعلى للاشتراك السنوي الذي تبقى عنده المنصة أوفر.
المالية - حوّله إلى صورة يفهمها مجلس الإدارة
54.8 شهرًا-فردًا في السنة ÷ 12 = نحو 4.6 موظفين تقنيين بدوام كامل. أي أن المنصة أوفر ما دام اشتراكها السنوي أقل من تكلفة أربعة موظفين تقنيين ونصف تقريبًا.
المدير التنفيذي - قارن بعرض السعر الفعلي
ضع الاشتراك السنوي الوارد في عرض المورد مقابل هذا الحد، بعد أن تحسب (ت) من واقع رواتب سوقك.
المالية
ماذا لو تأخر البناء ستة أشهر؟
في السيناريو المتحفظ يستغرق البناء 18 شهرًا بدل 12: يصبح البناء الأول 8.5 × 18 = 153ت، وتنخفض أشهر الصيانة إلى 42 شهرًا فتصبح 4 × 42 = 168ت، وإدارة المنتج 0.5 × 42 = 21ت. المجموع 342ت، والحد الأعلى للاشتراك يرتفع إلى (342 − 44) ÷ 5 = 59.6ت في السنة. والأهم من الرقم أن المنشأة تبقى سنة ونصفًا دون النظام الجديد، بينما يعمل مسار المنصة خلال أسابيع إلى أشهر بحسب حجم الإعداد والترحيل.
خطأ شائع: مقارنة عرض شركة البرمجة لبناء النسخة الأولى (102ت في المثال) بمجموع اشتراكات خمس سنوات. هذه مقارنة لسنة واحدة من جانب بخمس سنوات من الجانب الآخر، وهي تُسقط أكبر بند في البناء: الصيانة المستمرة.
مخاطر لا تظهر في الأرقام، ومن يتحمل كلًا منها
| الخطر | في البناء من الصفر | في المنصة مع التخصيص |
|---|---|---|
| تأخر التشغيل | تتحمله المنشأة كاملًا، وتبقى على نظامها القديم | محدود بمدة الإعداد والترحيل، والتخصيص يُبنى بالتوازي |
| رحيل المطور الأساسي | خطر مباشر على استمرار النظام | يتحمله المورد بفريقه، ويُضبط بالعقد |
| تغير المتطلبات النظامية | مشروع تطوير جديد في كل مرة | تحديث من المورد يصل كل عملائه |
| حادث أمني | مسؤولية المنشأة تصميمًا وتشغيلًا واستجابة | مسؤولية مشتركة بحسب خيار النشر والعقد |
| الدين التقني | يتراكم إن ضغط الجدول على الجودة، وتدفعه المنشأة لاحقًا | على المورد، ويظهر أثره في جودة التحديثات |
| الاعتماد على المورد | أقل، إن امتلكت الشيفرة والوثائق والفريق | أعلى، ويُعالج بحق تصدير البيانات وبنود الخروج |
الصف الأخير هو الحجة الأقوى للبناء، وهو حقيقي. لكن علاجه في المنصة ممكن بالعقد: ملكية البيانات، وتصديرها بصيغة مقروءة في أي وقت، وتسليمها كاملة عند الإنهاء.
متى يكون البناء منطقيًا فعلًا؟ شجرة قرار
- نعمالبناء قد يكون منطقيًا، بشرط فريق دائم وميزانية صيانة لخمس سنوات على الأقل.
- لابعد تصنيف متطلباتكم إلى جاهز وإعدادات وتطوير، هل تغطي منصة قائمة معظمها؟
- نعممنصة مع تخصيص للجزء المتبقي.
- لاهل الجزء غير المغطى منفصل، ويمكن بناؤه وحدةً ترتبط بالمنصة عبر واجهة برمجية؟
- نعممسار هجين: المنصة للتشغيل المعتاد، ووحدة مخصصة للجزء الفريد.
- لاهل تستطيعون تمويل فريق دائم وتحمل سنة أو أكثر قبل التشغيل؟
- نعمالبناء، بحوكمة صارمة: مالك منتج متفرغ، ومراحل بمخرجات، وملكية الشيفرة والوثائق.
- لاراجعوا المتطلبات: بعض ما يبدو فريدًا عادة عمل قديمة يمكن تغييرها.
- نعم
- نعم
- نعم
المسار الهجين تحديدًا يحتاج شروطًا تحمي التحديثات والبيانات: من يملك شيفرة الوحدة، وكيف تتوافق مع تحديثات المنصة، ومن يصونها. تفصل ذلك مقالة إضافة وحدات جديدة للنظام الطبي، ويعرض توثيق الواجهات البرمجية في صفحة التكاملات طريقة الربط.
ما الذي يحدد تكلفة التخصيص في مسار المنصة؟
حتى لا يتحول «التخصيص» إلى بناء من الصفر بتكلفة مفتوحة، افهم مكوناته قبل التعاقد:
- الإعدادات: الحقول والنماذج والحالات ومسارات الموافقة والتقارير والأسعار والقوالب المطبوعة. في المنصة تُضبط من الشاشات وهي مشمولة في الاشتراك ضمن مستوى الضبط من الإعدادات. كلما صنفت متطلبًا هنا وفرت تطويرًا.
- التطوير المخصص: ما يتجاوز الإعدادات، مثل منطق حسابي خاص أو شاشة كاملة جديدة. يُسعّر بتقدير مكتوب يحدد النطاق والمدة ومعايير القبول قبل البدء.
- التكاملات: لكل نظام خارجي تكلفة ربط مرة واحدة، تظهر بندًا مستقلًا في مكونات عرض السعر.
- البقاء مع التحديثات: التخصيص الذي يُبنى امتدادًا للمنصة يبقى مع كل تحديث. أما تعديل نسخة خاصة من النظام فيجعل كل تحديث مشروعًا جديدًا، فاسأل عن ذلك صراحة.
أسئلة التعاقد التي تمنع التخصيص من التحول إلى تطوير مفتوح، مثل سقف التقدير ومعايير القبول وملكية الشيفرة، تفصلها مقالة كيف تختار نظامًا طبيًا قابلًا للتخصيص.
كيف تحسم القرار بأرقامك خلال أسبوعين
- اكتب قائمة المتطلبات الخاصة
ما لا تجده في الأنظمة المعتادة، مع سبب كل متطلب ومن يستخدمه. استبعد ما هو تفضيل شكلي.
مدير التشغيل والمدير الطبي - اطلب تصنيفها من مورد منصة
جاهز، أو إعدادات، أو تطوير مخصص بتقدير مكتوب. هذا التصنيف وحده يكشف حجم ما يبرر البناء.
المورد - اطلب تقديرًا لبناء الفريق نفسه
من شركة برمجة أو من فريقك التقني: الأدوار والمدة للنسخة الأولى، وحجم فريق الصيانة بعدها.
مدير التقنية - احسب (ت) ونقطة التعادل
بالجدول السابق وأرقامكم، وبالسيناريو المتحفظ للتأخر.
المالية - مرر النتيجة على شجرة القرار
واكتب القرار بأسبابه ومخاطره المقبولة.
المدير التنفيذي
تعمل الحلول الواقعية لتقنية المعلومات بمنهجية مكتوبة تبدأ بفهم طريقة عملكم وتنتهي بنطاق وتكلفة ومعايير قبول قبل أي تطوير. وإن كانت قائمة متطلباتكم الخاصة جاهزة، أرسلها واطلب تصنيفها وتقديرًا مكتوبًا لما يحتاج تخصيصًا، فتدخل أرقامها مباشرة في حساب نقطة التعادل.
أسئلة شائعة
هل نملك النظام إذا بنيناه عبر شركة برمجة؟
ليس تلقائيًا. الملكية تحددها بنود العقد: ملكية الشيفرة المصدرية، وتسليمها مع الوثائق وبيئة البناء، وحقوق المكتبات المستخدمة. عقد لا ينص على ذلك قد يترككم تدفعون ثمن البناء دون قدرة على تغيير المورد.
هل يمكن البدء بالمنصة ثم البناء لاحقًا إن احتجنا؟
نعم، بشرط أن يضمن العقد تصدير البيانات كاملة بصيغة مقروءة. تشغيل المنصة سنتين يعطيكم أيضًا فهمًا دقيقًا لما تحتاجونه فعلًا، فإن قررتم البناء بعدها كانت متطلباتكم أوضح وأقل كلفة.
ماذا لو كانت لدينا إدارة تقنية داخلية قوية؟
وجود الفريق يخفض المخاطر لكنه لا يلغي التكلفة: وقته في بناء نظام إدارة عيادات وصيانته هو وقت لا يُصرف على أولويات أخرى. كثير من المجموعات ذات الفرق القوية تختار المنصة وتوجه فريقها إلى التكاملات والتقارير والوحدات الفريدة.
هل تشمل تكلفة التخصيص الصيانة بعد التسليم؟
يعتمد ذلك على العقد. في المنصة يُبنى التطوير المخصص امتدادًا يبقى مع التحديثات ويشمله الدعم الفني بعد التسليم، لكن اطلب ذلك مكتوبًا لكل مورد، ومعه ما يحدث للتخصيص إن تغير هيكل المنصة في إصدار كبير.
هل الحساب بالشهر-فرد دقيق بما يكفي لقرار استثماري؟
هو دقيق بما يكفي للمفاضلة بين المسارين، لأن أكبر بنود البناء أجور فرق. للقرار النهائي أضف الاستضافة واختبارات الأمن والتراخيص بمبالغها الفعلية، واحسب القيمة الزمنية للنقد إن كانت سياسة منشأتكم تتطلب ذلك.