التطوير المخصص يناسبك فقط حين يكون سير عمل الدعم لديك ميزة تنافسية لا يشبهها أحد، ولديك فريق تطوير دائم يتحمّل الصيانة سنوات. في كل ما عدا ذلك، الاشتراك في نظام جاهز أسرع وأقل مخاطرة، لأن الكلفة الحقيقية للبناء ليست في النسخة الأولى بل في صيانتها بعد رحيل من بناها.
هذا السؤال يصل عادةً بعد اجتماع يقول فيه أحدهم: «لدينا فريق تطوير، فلماذا ندفع اشتراكًا شهريًا بينما نستطيع بناء ما نريد بالضبط؟». المنطق سليم في ظاهره، والخلل فيه ليس في الحساب بل في ما لم يدخل الحساب أصلًا. القرار الصحيح لا يُتخذ بمقارنة سعر الاشتراك بتكلفة البناء، بل بمقارنة ما ستملكه فعليًا بعد سنتين في كل مسار.
«بناء أم شراء؟» سؤال عن المخاطر لا عن السعر
حين تشترك في نظام جاهز فأنت تشتري نتيجة: نظام يعمل هذا الأسبوع، وطرفًا آخر مسؤولًا عن إبقائه يعمل. وحين تبني، فأنت لا تشتري نتيجة بل تتحمّل التزامًا: التزامًا بأن تظل داخل منشأتك جهة تفهم هذا الكود وتصونه وتحدّثه ما دام مستخدَمًا. الاشتراك مصروف تشغيلي تستطيع إيقافه؛ النظام المبني داخليًا أصل ومسؤولية دائمة لا تنتهي بتسليم المشروع.
لذلك فالسؤال العملي ليس «أيهما أرخص؟» بل ثلاثة أسئلة أوضح:
- هل سير عمل الدعم لدينا فريد فعلًا بدرجة لا يستوعبها نظام قابل للتهيئة؟
- هل نملك — ونضمن استمرار — جهة مسؤولة عن صيانة هذا النظام لسنوات قادمة؟
- ما تكلفة التأخير؟ ماذا يخسر الدعم لدينا خلال الأشهر التي سيستغرقها البناء؟
السؤال الثالث هو الغائب دائمًا عن الجداول المالية. المنشأة التي تدير دعمها اليوم عبر البريد وجدول بيانات لا «تتوقف» بانتظار البناء؛ هي تواصل خسارة الطلبات وتجاوز المهل وتكرار الشرح، وكل شهر تأخير له ثمن تشغيلي حقيقي لا يظهر في أي بند من بنود المشروع. هذا الثمن يُدفع فعلًا، لكنه لا يُحتسب لأنه لا تصله فاتورة.
ما الذي تبنيه فعليًا حين تبني «نظام تذاكر»؟
التقدير الأولي لمشروع البناء يُكتب دائمًا في العمود الأوسط من الجدول التالي، والتنفيذ يجري في العمود الأيسر. لا شيء في هذه القائمة مستحيل، وكل بند فيها حُلّ آلاف المرات من قبل — لكن الفارق بين العمودين ليس أسابيع، بل أضعافًا.
| المكوّن | كيف يبدو في التقدير الأولي | ما يظهر فعليًا عند التنفيذ |
|---|---|---|
| نموذج التذكرة وحالاتها | «جدول في قاعدة البيانات» | دورة حياة كاملة بحالات وانتقالات مشروطة، وقواعد تحدد من يملك نقل ماذا، ومنع الحالات المتناقضة |
| محرك المهل (SLA) | «حقل تاريخ استحقاق» | عدّاد يحترم تقويم العمل والعطل الرسمية، ويتوقف عند التعليق، ويُعاد حسابه عند تغيّر الأولوية، ويطلق تنبيهًا قبل الخرق لا بعده |
| التوجيه والإسناد | «قائمة منسدلة بالموظفين» | قواعد إسناد حسب الفئة والمناوبة والحمل الحالي، وماذا يحدث حين يكون المسؤول في إجازة |
| استقبال البريد وتحويله لتذاكر | «نقرأ صندوق الوارد» | فك الترميز، والردود المقتبسة، والمرفقات، والتوقيعات، وربط الرد بالتذكرة الصحيحة، ومنع حلقة الردود التلقائية اللانهائية |
| الصلاحيات | «مدير ومستخدم» | أدوار متعددة المستويات، ورؤية محدودة حسب الفريق أو الفرع أو العميل، ومنع تسريب بيانات عميل إلى آخر |
| سجل التدقيق | «حقل آخر تعديل» | سجل غير قابل للتعديل لكل تغيير: من، ومتى، وما القيمة قبل وبعد |
| التقارير | «صفحة إحصائيات» | تجميعات زمنية، ونسب مئوية، وتقسيم حسب أي بُعد، وأداء مقبول بعد أن تصبح البيانات مئات الآلاف من الصفوف |
| العربية وواجهة RTL | «نترجم النصوص» | اتجاه كامل للواجهة، وفرز عربي صحيح، ومعالجة الهمزات والتشكيل في البحث، وتواريخ هجرية وميلادية، ونصوص مختلطة بأرقام وروابط |
| الإشعارات | «نرسل بريدًا» | قناة موثوقة لا تسقط رسائلها في السلة المهملة، وتفضيلات لكل مستخدم، وضبط لا يغرق الجميع بإشعارات يتوقفون عن قراءتها |
اقرأ العمود الأيسر بعين مدير المشروع لا بعين المطوّر: كل صف فيه ليس ميزة واحدة بل عائلة قرارات. قارن هذه القائمة بما تحصل عليه جاهزًا ضمن مزايا نظام تذاكر الدعم الفني لتعرف حجم ما تتعهّد ببنائه من الصفر.
التكلفة عبر خمس سنوات لا عبر سنة واحدة
أكثر ما يشوّه المقارنة أنها تُبنى على السنة الأولى. مشروع البناء يبدو فيها منافسًا لأن تكلفته تظهر مرة واحدة، بينما يظهر الاشتراك متكررًا إلى الأبد. مدّ الجدول إلى خمس سنوات وستتغير الصورة، لأن البناء أيضًا يتكرر — لكن تحت مسمّى «صيانة» لا «اشتراك».
| البند | التطوير المخصص | الاشتراك في نظام جاهز |
|---|---|---|
| السنة الأولى | تطوير وبنية تحتية وإدارة مشروع — وهو الرقم الوحيد الذي يُعرض عادةً في العرض التقديمي | اشتراك وتهيئة وتدريب |
| السنوات التالية | صيانة وإصلاح أخطاء وتحديثات أمنية وتوافق مع بيئات جديدة وطلبات تحسين لا تنتهي | اشتراك متجدد؛ التطوير على حساب المورّد |
| كل ميزة جديدة | مشروع صغير له تقدير وأولوية، يزاحم بقية أعمال التقنية على الموارد نفسها | تصل ضمن التحديثات، غالبًا بلا فاتورة إضافية |
| الأمن | مسؤوليتك كاملة: مراجعة الكود، وترقيع المكتبات، والاختبار الدوري | موزّعة بينك وبين المورّد حسب العقد — اقرأ حدودها قبل التوقيع |
| المعرفة بالنظام | مركّزة في أشخاص؛ رحيل مطوّر واحد قد يجمّد التطوير أشهرًا | لدى المورّد؛ لا تتأثر بدورانك الوظيفي |
| زمن الوصول إلى أول تذكرة حقيقية | أشهر | أيام إلى أسابيع حسب النطاق |
| الخروج | لا مورّد لتغيّره — لكن لا مخرج أيضًا؛ أنت عالق مع ما بنيت | تكلفة تبديل حقيقية، تُخفّف باشتراط تصدير كامل للبيانات في العقد |
في المقابل، الاشتراك رقم معلوم مسبقًا وقابل للإدراج في الميزانية بلا مفاجآت. اشتراك TixDesk يبدأ من 149 ريالًا شهريًا، وهو رقم تستطيع مقارنته مباشرة — لا مجازًا — بتكلفة أيام عمل مطوّر واحد. هذه المقارنة وحدها تحسم جزءًا كبيرًا من النقاش قبل الدخول في التفاصيل. ولبناء الأرقام بمنهجية دفاعية أمام المالية، راجع حساب العائد على الاستثمار لنظام التذاكر.
متى يفوز التطوير المخصص فعلًا؟
- كان سير عمل الدعم نفسه منتجًا تبيعه أو ميزة تنافسية يصعب على غيرك تقليدها
- لديك تكاملات عميقة مع أنظمة داخلية مغلقة لا تملك واجهات برمجية، ولا سبيل لربطها بأي نظام خارجي
- لديك فريق تطوير دائم ممول ضمن الهيكل الوظيفي، لا فريق مشروع يُحلّ بعد التسليم
- متطلباتك مستقرة وموثّقة، فالبناء استثمار في هدف ثابت لا مطاردة لهدف متحرك
- تملك حوكمة تقنية حقيقية: مراجعة أمنية، واختبار، وتوثيق — لا مجرد قدرة على كتابة كود
- كان الدافع الأساسي «توفير الاشتراك» — هذا وحده لا يصمد أمام حساب خمس سنوات
- تحتاج تشغيلًا خلال هذا الربع؛ البناء لا يمنحك ذلك مهما ضغطت
- متطلباتك غير محسومة وستكتشفها أثناء التشغيل — وهذا طبيعي ومتوقع، لكنه عدوّ البناء
- فريق التقنية لديك مثقل أصلًا بما لا يستطيع إنجازه
- ما تحتاجه فعليًا هو تهيئة: نماذج وحقول وقواعد إسناد وتقارير — وهذه إعدادات في الأنظمة الجاهزة لا مشاريع برمجية
لاحظ النمط: كل مبررات البناء الصحيحة تدور حول التفرّد والقدرة المؤسسية، ولا يدور أي منها حول السعر. حين يكون السعر هو المبرر الوحيد المطروح على الطاولة، فالقرار غالبًا خطأ — ليس لأن التوفير غير مشروع، بل لأنه أول ما يتبخّر حين يتأخر المشروع ربعين ويستهلك مطوّرين كانا مخصصين لعمل آخر.
ورقة قرار تملؤها بنفسك
بدل الجدل النظري، أعطِ كل سؤال درجة من 0 إلى 3 حسب حالتك، ثم اجمع.
| المحور | 0 درجة | 3 درجات |
|---|---|---|
| تفرّد سير العمل | يشبه الدعم في أي منشأة مماثلة | لا يشبهه شيء، ولم تجد نظامًا يستوعبه بعد تجربة فعلية لا بعد قراءة كتيّب |
| استقرار المتطلبات | ستتغير كثيرًا خلال سنة | محسومة وموثّقة ومعتمدة |
| فريق التطوير | مشروع مؤقت أو مورّد خارجي بالساعة | فريق دائم ممول ضمن الهيكل الوظيفي |
| ملكية الصيانة | لم تُحدَّد بعد | جهة مسمّاة بميزانية سنوية معتمدة |
| ضغط الوقت | نحتاج التشغيل خلال شهرين | لدينا سنة كاملة ولا ضغط علينا |
| قيود التكامل | أنظمتنا تدعم واجهات برمجية حديثة | تكاملات عميقة مع أنظمة مغلقة قديمة لا منفذ لها |
| تحمّل المخاطر | تعثّر المشروع يعني توقفًا تشغيليًا | نتحمّل تعثّرًا وإعادة محاولة |
لا تبحث عن حدّ فاصل سحري في المجموع؛ هذه الورقة ليست آلة قرار بل كاشف اتفاق. قيمتها الحقيقية أن يملأها مدير التقنية ومدير الدعم والمالية كلٌّ على حدة ثم تُقارن النتائج. تباعد الدرجات في بند واحد يعني وجود افتراض غير معلن لدى أحد الأطراف — وهو بالضبط الافتراض الذي سيُفشل المشروع لاحقًا إن بقي غير مكتشف.
لكن هناك استثناء واحد لقاعدة «لا حدّ فاصل»: إن جاءت درجاتك منخفضة في «فريق التطوير» و«ملكية الصيانة» تحديدًا، فالنتيجة محسومة مهما ارتفعت بقية المحاور. سؤال «من سيصون هذا بعد سنتين؟» إن لم تكن له إجابة باسم ووظيفة وميزانية، فليس أمامك قرار بناء بل رغبة بناء.
الخيار الثالث الذي يُغفل: جاهز في النواة، مخصص عند الأطراف
تشغّل نظامًا جاهزًا للنواة — التذكرة، والمهل، والتوجيه، والسجل، والتقارير — ولا تبني بنفسك إلا ما هو خاص بك فعلًا: ربطًا مع نظامك المالي، أو شاشة داخلية تجمع بيانات من مصدرين، أو أتمتة تنفّذها عبر الواجهة البرمجية. تحصل على تشغيل خلال أسابيع، وتُبقي فريق تطويرك على العمل الذي يميّزك.
تملك تحكمًا كاملًا في كل تفصيل، وتدفع مقابله وقتًا وصيانة دائمة. مبرر فقط حين تكون النواة نفسها — لا الأطراف — هي المختلفة، وهي حالة نادرة أكثر مما يُظن.
إلى هذا الخيار ينتهي أغلب النقاش الجاد، لأنه يفصل بين ما هو «فريد» وما هو «مألوف». عدّاد المهلة ليس فريدًا في أي منشأة على وجه الأرض، وكذلك دورة حياة التذكرة وسجل التدقيق؛ أما ربط التذكرة برقم العقد في نظامك الداخلي فقد يكون فريدًا فعلًا. اشترِ الأول وابنِ الثاني.
ولهذا المسار شرط نجاح واحد: أن يملك النظام الجاهز واجهة برمجية حقيقية وموثّقة، لا وعدًا بها. وهذا أول ما تختبره بنفسك خلال فترة تجربة مجانية 14 يومًا بلا بطاقة ائتمان — لا أول ما تصدّقه من عرض تقديمي. الفرق بين واجهة برمجية موثّقة ومكتملة وأخرى «قيد التطوير» هو الفرق بين خيار ثالث ناجح ومشروع بناء بدأ متأخرًا.
وإن كان دافعك الأساسي للبناء هو ضبط الواجهة العربية بشكل صحيح — وهو دافع مشروع تمامًا وشائع أكثر مما يُعترف به — فاختبره قبل التسليم به: افتح النظام الجاهز، واكتب فيه نصًا عربيًا مختلطًا بأرقام وروابط، وافحص الفرز والبحث والتقارير والإشعارات المرسلة. النظام العربي في أصله يختلف عن نظام تُرجمت واجهته لاحقًا، والفارق يظهر في هذه التفاصيل بالذات لا في الصفحة الرئيسية.
الأسئلة الشائعة
كم يستغرق بناء نظام تذاكر داخلي؟
لا يمكن إعطاء رقم عام صادق، لأن المدة تتبع النطاق لا المسمّى. الطريقة الأصدق أن تقدّر بالمكوّنات لا بالإجمال: خذ جدول المكوّنات في هذا المقال، وقدّر كل صف على حدة مع فريقك، ثم اجمع وأضف الاختبار والتصحيح. الرقم الناتج غالبًا يفاجئ من طلب البناء، وهذه المفاجأة في حد ذاتها معلومة مفيدة قبل الالتزام.
ألا نوفّر المال على المدى الطويل إذا بنينا؟
هذا يعتمد كليًا على أفق الحساب. على سنة واحدة قد يبدو البناء أرخص؛ على خمس سنوات تدخل الصيانة والتحديثات الأمنية والميزات الجديدة، وكلها عمل مستمر يُدفع أجرًا لموظفين. التوفير الحقيقي يتحقق فقط إذا كان النظام سيخدم عددًا كبيرًا من المستخدمين لسنوات طويلة، ولديك فريق قائم أصلًا لا فريق تُنشئه لهذا الغرض.
هل التطوير المخصص يمنحنا سيطرة أفضل على البيانات؟
لا علاقة مباشرة بين الأمرين. ما يحدد موقع بياناتك وسيطرتك عليها هو الاستضافة ونموذج التشغيل، لا هوية من كتب الكود. نظام جاهز مستضاف داخل المملكة قد يعطيك سيطرة أعلى من نظام بنيته بنفسك ثم استضفته خارجها. القرار الصحيح أن تفصل سؤال «بناء أم شراء» عن سؤال الاستضافة كما هو مشروح في مقارنة الاستضافة السحابية والمحلية لنظام التذاكر.
لدينا نظام مبني داخليًا بالفعل — كيف نقرر تركه؟
لا تقرر بناءً على جودة الكود بل على تكلفة إبقائه. اسأل: كم طلب تحسين معلّق منذ أكثر من ستة أشهر؟ كم شخصًا يفهم هذا النظام اليوم؟ متى كانت آخر مراجعة أمنية؟ وكم تُنفق سنويًا لإبقائه فقط دون إضافة أي قيمة جديدة؟ إن كانت الإجابات مقلقة، فأنت لا تملك أصلًا بل تتحمّل دينًا تقنيًا. وابدأ في تلك الحالة من بناء الحجة الإدارية كما في نموذج دراسة الجدوى لتطبيق نظام إدارة التذاكر.
فريقنا يقول إن أي نظام جاهز لن يستوعب سير عملنا. كيف أتحقق؟
حوّل الادعاء إلى اختبار محدد. اطلب من الفريق كتابة أصعب ثلاث حالات لديكم بالتفصيل — لا عناوين عامة بل خطوات ومن يفعل ماذا ومتى — ثم حاولوا تنفيذها فعليًا داخل نظام جاهز خلال فترة التجربة. النتيجة إمّا أن يعمل النظام فتنتهي المسألة، أو يفشل في نقطة محددة يمكن عندها مناقشتها مع المورّد أو اعتبارها مبررًا موثّقًا للبناء. الخلاف على الانطباعات لا ينتهي؛ الخلاف على حالة اختبار ينتهي في يوم.