تطبيق ويب مخصص أم SaaS جاهز

لا يكاد أي مشروع تطوير تطبيق ويب مخصص يبدأ بوثيقة مواصفات. يبدأ بجدول بيانات أنشأه أحدهم لتتبع شيء واحد، ثم اكتسب عمودا ثانيا، ثم صفحة، ثم معادلة لا يفهمها سوى شخص واحد. وبعد ثلاث سنوات صار ذلك الملف يحمل الجدول الزمني والتسعير ونصف سجلات العملاء، ويحرره أربعة أشخاص في وقت واحد، ولا يستطيع أحد أن يجزم أي نسخة هي الحالية.

هذه هي نقطة القرار الحقيقية، وليست النقطة التي تعالجها معظم المقالات عن البناء مقابل الشراء. أنت لا تختار بين صفحة بيضاء ومنتج جاهز. أنت تختار بين ثلاثة مخارج من عملية تعمل لكنها هشة: شراء منتج، أو تركيب شيء على منصة بلا برمجة، أو طلب برمجيات مفصلة على طريقتك في العمل.

هل تبني تطبيق ويب مخصصا أم تشتري SaaS؟ اشترِ، إلا إذا تحقق شرطان على الأقل من ثلاثة: أن تكون العملية عامل تمايز تنافسي لا مجرد نفقات تشغيل، وألا يناسبها أي منتج دون أن يشوه طريقة عملك، وأن يكون عمل التكامل هو الجزء الأكبر من المهمة. وإذا تحقق شرط واحد فقط، فإن منتجا جاهزا مع تهيئة يكون أرخص في الغالب دائما. كما يحمل البناء المخصص أرضية تكلفة مستمرة تقارب 15 إلى 20 في المئة من سعر البناء كل عام، بلا نهاية.

جدول البيانات الذي صار عمودا حاملا

النمط محدد بما يكفي ليستحق اسما، وعادة ما يتعرف فريق على نفسه حين يسمعه مسمى.

يبدأ بشخص واحد وغرض واحد. يحتاج أحدهم إلى معرفة الأعمال المحجوزة هذا الأسبوع، فيفتح جدولا. ثم يحتاج شخص ثان إلى قراءته، فينتقل إلى قرص مشترك. ثم يحتاج ثالث إلى تحريره، فصار أكثر من واحد يكتب في الخلايا نفسها في اللحظة نفسها. ثم صفحة لكل شهر. ثم بحث مقابل ملف ثان. ثم ماكرو كتبه متعاقد غادر منذ زمن.

العلامات ثابتة دائما. اسم الملف يحمل تاريخا ولاحقة إصدار. هناك نسخة رئيسية والجميع يعرف من يحتفظ بها. وتدريب موظف جديد يعني أن تريه الملف بدل أن تشرح له العملية، لأن العملية غير مكتوبة في أي مكان آخر.

عند هذه النقطة لم يعد جدول البيانات مستندا. صار تطبيقا بلا ضبط للوصول، وبلا سجل تدقيق، وبلا تحقق من المدخلات، وبلا سياسة نسخ احتياطي تستطيع الدفاع عنها، وبقائم واحد على صيانته. إنه يعمل، وهذا بالضبط سبب عدم استبداله حتى الآن، وهو أيضا سبب كون استبداله مكلفا اليوم.

ما تكلفه الحال الراهنة فعليا

لا أحد يضع رقما على جدول البيانات، فيبدو مجانيا. وهو ليس كذلك، والحساب سهل أن تعيده على عملك أنت.

ابدأ بإعادة إدخال البيانات. إذا أمضى شخصان 45 دقيقة يوميا لكل منهما في نقل بيانات بين الجدول وبرنامج المحاسبة وصندوق بريد مشترك، فتلك سبع ساعات ونصف أسبوعيا، أي نحو 340 ساعة في سنة عمل من 45 أسبوعا. وبتكلفة محملة كاملة قدرها GBP 22 للساعة، فأنت تنفق قرابة GBP 7,500 سنويا على نسخ أرقام من شاشة إلى أخرى، وهذا لا يشتري شيئا سوى فرصة الوقوع في خطأ طباعي.

ثم أضف التسوية، حين يقارن أحدهم الجدول شهريا بالمصدر المعتمد ويقضي نصف يوم في تقرير أي نسخة هي الصحيحة. ثم أضف الأخطاء التي تكتشف متأخرة: عرض السعر المرسل بسعر الشهر الماضي، والعمل المحجوز مرتين، والتجديد الفائت. كل واحد منها مبلغ صغير وعميل منزعج، ولا يظهر أي منها في بند ميزانية.

ثم أضف مخاطرة الشخص الواحد. شخص واحد يفهم المعادلات، وحين يمرض ذلك الشخص أو يسافر أو يغادر، تهبط العملية إلى مستوى التخمين.

البيانات الشخصية في جدول بيانات تظل بيانات خاضعة للتنظيم

إذا كان الملف يحوي أسماء أو بيانات اتصال أو سجلات موظفين أو معلومات عملاء، فتلك بيانات شخصية، وينطبق عليها UK GDPR تماما كما ينطبق على قاعدة بيانات.

ومكتب مفوض المعلومات ICO صريح فيما يتطلبه ذلك. دليله لأمن البيانات ينص على أن من المبادئ الأساسية في UK GDPR معالجة البيانات الشخصية بأمان عبر تدابير تقنية وتنظيمية مناسبة، وأن تلك التدابير يجب أن تضمن سرية أنظمتك وسلامتها وتوافرها وسرية البيانات الشخصية داخلها. وجدول بيانات على حاسوب محمول لا يملك صلاحيات على مستوى الصف، ولا قاعدة احتفاظ، ولا سجلا لمن قرأ ماذا، وهو ينسخ نفسه كاملا في كل مرة يرسله فيها أحد بالبريد.

والعواقب ليست نظرية. ففي أكتوبر 2024 غرم ICO جهاز شرطة أيرلندا الشمالية بمبلغ GBP 750,000 بعدما كشفت بيانات مخفية في جدول بيانات نشر استجابة لطلب حرية معلومات عن ألقاب وأحرف أسماء ورتب وأدوار 9,483 من ضباط الجهاز وموظفيه جميعا. قرار الإنفاذ يستند إلى المواد 5(1)(f) و32(1) و32(2). ولولا نهج ICO تجاه القطاع العام لكانت الغرامة GBP 5.6 مليون.

كل مؤسسة تدير عملية على جداول البيانات لديها ورقة عمل كهذه في مكان ما.

اشترِ المنتج: متى يكون SaaS هو الصواب الواضح

هذه هي الإجابة في أغلب الأحيان، وتستحق أن يدافع عنها أولا لا أن تلخص في فقرة ختامية.

إذا كانت عمليتك شائعة فالمنتج موجود، وهو أرخص من أي شيء تستطيع بناءه. الرواتب، والمصروفات، وتذاكر الدعم، وحجز المواعيد، والتوقيع الإلكتروني، ومسك الدفاتر، وتتبع المتقدمين للوظائف. أنفق أحدهم عقدا كاملا وفريق هندسة كبيرا على الحالات الطرفية التي لم تصادفها أنت بعد: خلل السنة الكبيسة، وتغير نسبة ضريبة القيمة المضافة، والاسترداد الذي يصل بعد إقفال الفترة.

كما أنك تشتري عملا كنت ستدفع ثمنه على أي حال. المورد يتحمل زمن التشغيل، وترقيع الأمن، وتقلب المتصفحات، وعمل إتاحة الوصول، وأدلة الامتثال التي يطلبها عملاؤك. لا شيء من ذلك يظهر كخاصية، وكله مال حقيقي.

الاختبار الأمين ليس هل يفعل المنتج كل شيء. الاختبار هو هل ينجز الثمانين في المئة المهمة دون أن يجبرك على تغيير شيء تهتم به. وإذا كان الاختلاف الوحيد أن فريقك يقول عمل والبرنامج يقول تذكرة، فاشترِ البرنامج وغير الكلمة.

الشروط الثلاثة التي تبرر تطوير تطبيق ويب مخصص

البناء المخصص تبرره الاستراتيجية لا الانزعاج. هناك ثلاثة شروط تسنده فعلا، والقاعدة المفيدة أنك تحتاج إلى اثنين منها على الأقل. فالشرط الواحد وحده يحل دائما تقريبا بتكلفة أقل عبر منتج جاهز مع تهيئة. وينطبق الاختبار نفسه على مستوى المؤسسات الكبيرة، وهو ما يعالجه دليلنا للبناء مقابل الشراء في CRM وERP على مرتبة حجم مختلفة.

العملية عامل تمايز لا نفقات تشغيل

اسأل ماذا سيلاحظ العميل لو صارت العملية أفضل بمرتين. إذا كان الجواب لا شيء فهي نفقات تشغيل وينبغي أن تشتريها، لأن امتياز الرواتب لا يكسبك عملا جديدا. لكن مقاول تركيبات متخصصا يعصر منطق جدولته عملا إضافيا من يوم كل شاحنة، أو مقرضا تشكل قواعد تقييمه الائتماني منتجه الحقيقي، إنما يمرر ميزته التنافسية عبر ذلك البرنامج. لا يمكنك أن تشتري ميزة يستطيع منافسوك شراءها بالسعر الشهري نفسه.

لا منتج يناسبك دون تشويه العملية

كل منتج يرمز افتراضات عن كيفية سير العمل، والعلامة على أنها خاطئة بالنسبة إليك هي أن تبنيه سيقتضي منك التوقف عن شيء مربح. فإذا كانت شركتك تسعر على أساس لا يستطيع المنتج التعبير عنه، وكان ذلك الأساس هو سبب اختيار العملاء لك، فالمنتج يطلب منك أن تصير أكثر عادية مقابل رسوم ترخيص.

سطح التكامل هو العمل الفعلي

أحيانا لا يكون الجزء المهم في الشاشات أصلا. يكون في سحب المخزون من نظام، والأسعار من ثان، وتوافر الفنيين من ثالث، وكتابة النتيجة في رابع. وحين يكون معظم الجهد تكاملا، تصير واجهة الاستخدام طبقة رقيقة فوق سباكتك أنت، وتكون شاشات المنتج الجاهزة هي أقل ما تحتاج إليه. وهذا هو الشرط الأكثر استهانة به، وهنا يسكن فخ المنتصف.

فخ المنتصف: تشتري ثم تبني على أي حال

أغلى النتائج ليست أيا من الطريقين مسلوكا بنقاء. إنها أن تشتري منتجا لأنه بدا أرخص، ثم تنفق على ثنيه ليوافق عمليتك أكثر مما كان سيكلفه بناء مخصص، وتظل تدفع الترخيص فوق ذلك.

يحدث ذلك تدريجيا وكل خطوة منفردة قابلة للتبرير. المنتج لا يناسب، فتتعاقد مع شريك تنفيذ. يكتب الشريك تهيئة بلغة السكربتات الخاصة بالمورد، وهي شفرة برمجية، لكنها لا تبدو كذلك لأنها تعيش داخل المنتج. ثم تحتاج إلى ربطه بنظامين آخرين، فتشتري منصة تكامل. ثم يطلق المورد إصدارا رئيسيا فتحتاج تخصيصاتك إلى اختبار انحدار.

عند تلك النقطة تكون قد جمعت كل تكاليف البرمجيات المخصصة دون أي ملكية: قاعدة شفرة لا تستطيع قراءتها، مستضافة في مكان لا تتحكم فيه، مكتوبة بلغة لا توجد إلا في منتج واحد، يصونها شريك صار أجره اليومي بندا في ميزانيتك. ودليلنا عن تكلفة تطوير البرمجيات المخصصة يشرح كيف تتراكم تلك الأرقام.

علامات تحذيرية على أنك داخل الفخ

الفخ أسهل في الكشف منه في الخروج، والإشارات قاطعة بمجرد أن تبحث عنها.

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

الأخيرة هي الأوضح. إذا نجا جدول البيانات من شراء البرنامج، فالبرنامج لم يحل المشكلة.

البرمجة بلا شفرة وبأقل شفرة كطريق ثالث جاد

سؤال البناء بلا شفرة مقابل التخصيص يستحق أكثر من هامش، لأن منصات البرمجة بأقل شفرة كثيرا ما تكون الإجابة الصحيحة في تطوير الأدوات الداخلية، وهي ليست لعبة.

منصات مثل Airtable وRetool وMicrosoft Power Apps تتيح لك بناء تطبيق حقيقي متعدد المستخدمين بقاعدة بيانات ونماذج وصلاحيات وأتمتة، في أيام بدل أشهر، دون توظيف أحد. وهي تتولى الاستضافة والنسخ الاحتياطي والمصادقة وتخطيط الهاتف. ولمهمة محددة هي نقل جدول بيانات صار عمودا حاملا إلى شيء له ضبط وصول سليم وسجل تدقيق، تكون هذه المنصات غالبا أسرع طريق إلى خفض كبير في المخاطر.

كما أنها تسعر لكل مقعد، وهذه هي الحقيقة التي تحدد ما إذا كانت ستظل الإجابة الصحيحة وأنت تكبر.

أين ينتصر البناء بلا شفرة حقا

ينتصر حين يكون شكل المشكلة سجلات ونماذج وطرق عرض وقواعد بسيطة: سجل أصول، أو طابور موافقات، أو قائمة تحقق لاستقبال عميل، أو حجز قاعات. وينتصر بأشد صوره حين يستطيع الشخص الذي يفهم العملية أن يبنيها بنفسه، لأن المتطلبات عندئذ لا تحتاج إلى النجاة من ترجمة إلى وثيقة مواصفات ثم العودة منها.

وينتصر أيضا في زمن الوصول إلى القيمة. فأداة تعمل خلال أسبوعين وتستخدم كل يوم أفضل من أداة مثالية بعد ستة أشهر ولا تزال في التصميم، والنسخة المبنية تعلمك ما كانت المتطلبات عليه فعلا.

أين يصطدم البناء بلا شفرة بجدار

الجدار عادة واحد من خمسة أمور. الأداء عند أعداد الصفوف الحقيقية، متى وجب على طريقة عرض أن ترشح مئات الآلاف من السجلات. والصلاحيات ذات التعقيد الحقيقي، مثل قواعد على مستوى الصف تعتمد على حالة السجل وفريق الناظر إليه. وسلامة المعاملات، حيث يجب أن يحدث أمران معا أو لا يحدث أي منهما. والاختبار وإدارة الإصدارات، لأنه غالبا لا سبيل إلى مراجعة تغيير قبل نشره. وأي شيء فيه آلة حالات حقيقية، حيث تحكم القواعد أي انتقال مسموح.

أنت لا تصل إلى الجدار تدريجيا. تصل إليه حين يتبين أن تغييرا كان يفترض أن يستغرق ساعة صار مستحيلا.

ما يفعله التسعير لكل مقعد عند التوسع

التسعير لكل مقعد رخيص عند عشرة مستخدمين وقد يصير غير قابل للدفاع عند أربعمئة، والأسعار المنشورة تجعل ذلك سهل البرهان.

صفحة أسعار Retool تدرج خطة Business لسحابة المملكة المتحدة بمبلغ GBP 40 شهريا لكل مطور وGBP 12 لكل مستخدم داخلي، مع خطة Team بمبلغ GBP 8 وGBP 4. وتدرج Microsoft خطة Power Apps Premium بمبلغ GBP 16.90 لكل مستخدم شهريا بالدفع السنوي، دون ضريبة القيمة المضافة، وتنخفض إلى GBP 10.80 مع حد أدنى قدره 2,000 مقعد. وتنشر Airtable خطة Team بمبلغ USD 20 وخطة Business بمبلغ USD 45 لكل مستخدم شهريا، وكلتاهما تفوتر سنويا بالدولار الأمريكي.

اسحب هذه الأرقام إلى الأمام. أربعون مستخدما على Retool Business، ثلاثة منهم مطورون، يكلفون نحو GBP 6,800 سنويا. والشكل نفسه عند أربعمئة مستخدم يقارب GBP 59,600 سنويا، ويرتفع من جديد لحظة إضافة أشخاص. وعلى Power Apps Premium يكلف أربعمئة مقعد نحو GBP 81,000 سنويا قبل ضريبة القيمة المضافة.

لا شيء من هذه الأسعار غير معقول. المقصود أن الفاتورة تتبع عدد الموظفين لا القيمة المسلمة، وعدد الموظفين ينمو.

مشكلة الخروج حين يعيش المنطق داخل أداة مملوكة

كل منصة ستصدر بياناتك. ولا واحدة منها ستصدر تطبيقك.

الصفوف تخرج بصيغة CSV أو عبر واجهة برمجية، وهذا هو الجزء الذي يتفقده الجميع قبل التوقيع. أما ما لا يخرج فهو الشيء الذي بنيته: الأتمتة، وأعمدة المعادلات، وقواعد الصلاحيات، والنماذج الشرطية، والمسار الذي يحول طلبا إلى ثلاثة إشعارات وتغيير حالة. ذلك المنطق هو الأصل، وقد كلف شهورا من القرارات حتى استقام، ولا يستطيع تشغيله إلا محرك مورد واحد.

والنتيجة العملية أن مغادرة منصة بأقل شفرة ليست ترحيلا بل إعادة بناء. تستعيد بياناتك وتكتب التطبيق مرة أخرى في مكان آخر، انطلاقا من مواصفات لم تكتب قط لأن المنصة كانت هي المواصفات.

وهذه ليست حجة ضد استخدام واحدة منها، بل حجة لصالح الاحتفاظ بوصف مكتوب للقواعد خارج الأداة.

التكلفة الكلية للملكية على خمس سنوات في الطرق الثلاثة

المقارنة التي يجريها الناس عادة غير أمينة بطريقة محددة: تضع النسخة المحسوبة بالكامل من طريق مقابل السعر المعلن لطريق آخر. خذ أربعين مستخدما وتطبيقا تشغيليا واحدا يحل محل جدول بيانات واشتراكين صغيرين. الأرقام قيم تخطيطية توضيحية لا عروض أسعار، وسعر البناء عندك هو المتغير الأكثر حركة.

بالكلام: عند أربعين مستخدما تفوز المنصة بلا شفرة، بنحو GBP 75,800 على خمس سنوات. ويأتي البناء المخصص ثانيا عند نحو GBP 94,500، لأن بناء بمبلغ GBP 45,000 مع GBP 1,800 استضافة وGBP 8,100 صيانة سنوية يظل يتفوق على ترخيص طريق SaaS ووسيطه وإدارته مكدسة معا. أما شراء المنتج فيأتي أخيرا عند نحو GBP 135,000، ويأتي كذلك بسبب فخ المنتصف لا بسبب الترخيص وحده.

لماذا ينقلب الجدول نفسه عند أربعمئة مستخدم

غير مدخلا واحدا، وهو عدد الموظفين، فيتبدل الترتيب تماما. وهذا هو السبب الأكثر شيوعا في أن يصير البناء قرارا عقلانيا.

عند أربعمئة مستخدم يبلغ ترخيص SaaS بسعر GBP 30 لكل مقعد شهريا مبلغ GBP 144,000 سنويا وحده، ومع الوسيط نفسه وعبء إداري أكبر يتجاوز الإجمالي على خمس سنوات مبلغ GBP 800,000. أما طريق البناء بلا شفرة فيستقر قرب GBP 375,000. والبناء المخصص يكاد لا يتحرك: مستخدمون أكثر يعني فاتورة استضافة وميزانية صيانة أكبر قليلا، حتى إن مضاعفة سعر البناء إلى GBP 70,000 تبقي الإجمالي على خمس سنوات قرب GBP 153,000.

والسبب بنيوي. فالتسعير لكل مقعد تكلفة متغيرة تتوسع مع مؤسستك، بينما النظام المخصص تكلفة ثابتة مع جزء متغير صغير، وذلك الجزء بنية تحتية، وهي رخيصة. أما هل يعنيك هذا الانقلاب فذلك تنبؤ تجاري لا حكم تقني.

أرضية التكلفة المستمرة لبناء مخصص

البند الذي يحذفه الناس من تقدير مخصص هو البند الذي لا يتوقف أبدا. للتطبيق المفصل أرضية تكلفة، وهي لا تهبط إلى الصفر في سنة هادئة لا يطلب فيها أحد ميزة جديدة.

تتكون الأرضية من الاستضافة والمراقبة ونسخ احتياطية جربت الاستعادة منها فعلا وشهادات TLS وترقيع الأمن وترقية الاعتماديات وشخص يرد على الهاتف حين يتعطل النظام في التاسعة صباح الاثنين. خطط لنحو 15 إلى 20 في المئة من تكلفة البناء الأصلية كل عام. هذا افتراض تخطيطي مستمد من سلوك هذه المشاريع لا إحصاء منشور، لكنه الرقم الذي نضع ميزانياتنا عليه، وعرض السعر الذي يخلو منه ليس عرضا كاملا. ومقالنا عن تكلفة صيانة البرمجيات يفصله أكثر.

كل إجمالي خمسي للبناء المخصص أعلاه يفترض أن هذا البند ممول. والمشاريع التي تتخطاه لا توفر المال، بل تؤجله وتدفعه لاحقا على هيئة إعادة كتابة، وهو بالضبط ما يصفه الدين التقني.

البرمجيات التي لا تصان تتحلل

التطبيق الذي ظل يعمل دون أن يمسه أحد لعامين ليس مستقرا. إنه غير مرقع، والفرق مهم.

لم يتغير شيء في شفرتك، لكن كل ما حولها تغير. فبيئات تشغيل اللغات تبلغ نهاية عمرها وفق جدول منشور: Node.js يدعم حاليا الإصدار 26 بوصفه الإصدار الجاري، مع الإصدارين 24 و22 كخطي دعم طويل الأمد نشطين، ما يعني أن أي شيء مبني على الإصدار 20 أو أقدم صار خارج الدعم ولا يتلقى إصلاحات أمنية. والاعتماديات تراكم ثغرات منشورة. والمتصفحات تغير طريقة تعاملها مع ملفات تعريف الارتباط والتخزين. ومزودو الدفع يوقفون إصدارات واجهاتهم ويمنحونك موعدا نهائيا.

لا شيء من هذا خطؤك، وكله مشكلتك، لأنه لا يوجد في نظام مفصل مورد يمتصه نيابة عنك. وهذه هي الميزة البنيوية الحقيقية للشراء: فريق هندسة شخص آخر يمضي كل أسبوع في منع الأرضية من التعفن، ورسوم الترخيص هي ثمن ذلك. وميزانية صيانتك تشتري العمل نفسه بالضبط، وأنت تدفعها إما عن قصد وإما في حالة طوارئ.

إيجاد نقطة التعادل الخاصة بك لكل مقعد

تستطيع حساب نقطة التعادل في نحو عشر دقائق، وهي أقنع لمدير مالي من أي حجة عن الملكية.

خذ التكلفة الشهرية لطريق المنتج بكل شيء: الترخيص والوسيط وجزء الراتب المنفق على إدارته. اطرح منها التكلفة الشهرية لتشغيل نظام مخصص، وهي الاستضافة زائد جزء من اثني عشر من ميزانية الصيانة السنوية. اقسم سعر البناء على ما تبقى. الناتج هو عدد الأشهر حتى يسدد البناء نفسه.

بالحساب عند أربعين مستخدما: يعمل طريق SaaS بنحو GBP 2,150 شهريا، والنظام المخصص بنحو GBP 825، فيكون التوفير الشهري نحو GBP 1,325. وبناء بمبلغ GBP 45,000 ينقسم على ذلك نحو 34 مرة، فتقع فترة الاسترداد قرب عامين وعشرة أشهر. وعند أربعمئة مستخدم تهبط فترة الاسترداد إلى ما دون العام.

تحفظان اثنان. سعر البناء هو أقل الأرقام يقينا هنا، فاحسبه بعرض السعر الذي تلقيته ثم أعد حسابه بزيادة 50 في المئة. وفترة استرداد تتجاوز ثلاثة أعوام تقريبا حجة ضعيفة، لأن عمليتك قد لا تبقى على حالها كل هذه المدة.

البيانات والاحتجاز يقطعان في الاتجاهين

الاحتجاز لدى المورد هو الحجة المعتادة للبناء، وهو حقيقي. لكنه نصف الصورة أيضا، لأن النظام المخصص الذي لم يوثقه أحد محتجز هو الآخر.

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

وفي الجانب المخصص، الخطر المكافئ والمعاكس هو نظام بناه متعاقد واحد بلا ملف README ولا اختبارات ولا دليل تشغيل، ببيانات اعتماد في ملف تهيئة على حاسوب محمول ومستودع في حساب شخصي لأحدهم. وهذا أسوأ من الاحتجاز لدى مزود SaaS، لأن المورد على الأقل لا يزال قائما.

والعلاجات تعاقدية ورخيصة الاشتراط في البداية. امتلك المستودع بنفسك، واشترط التوثيق ودليل التشغيل بوصفهما مخرجات مسماة، واشترط أن يتمكن مهندس ثان من نشر النظام من ذلك التوثيق وحده. واختبر هذا الادعاء قبل الدفعة الأخيرة. ودليلنا الكامل للمشتري يتناول بنود العقد بتفصيل أكبر.

الأمن والامتثال في كل نموذج

توزيع المسؤولية يختلف بحسب الطريق، لكن شيئا واحدا لا يتحرك إطلاقا، والخطأ فيه شائع.

بموجب UK GDPR أنت المتحكم في البيانات. ويعرف ICO المتحكم بأنه الجهة التي تحدد، منفردة أو بالاشتراك مع غيرها، أغراض معالجة البيانات الشخصية ووسائلها، ويعرف المعالج بأنه من يعالج البيانات الشخصية نيابة عن المتحكم. ومورد SaaS لديك هو المعالج في الغالب الأعم. وتبقى أنت مسؤولا عن إثبات الامتثال، ويقول ICO صراحة إن المتحكم مسؤول عن معالجيه وعليه أن يبرم عقدا ملزما يتضمن الأحكام التي تقتضيها المادة 28(3).

أما ما يحمله المورد فعلا فهو طبقة البنية التحتية: الأمن المادي، وترقيع المنصة، وضوابط الشبكة، وغالبا الشهادات. ونموذج المسؤولية المشتركة الصادر عن NCSC واضح في أنه حتى مع SaaS تبقى لديك ثلاثة أمور: تقييم أن الخدمة تلبي احتياجاتك الأمنية، وتهيئتها بأمان، وتقرير أي بيانات تضعها فيها.

وفي البناء المخصص ترث الطبقة التقنية كلها أيضا: الترقيع، وضبط الوصول، والتشفير، والتسجيل، والنسخ الاحتياطي والاستعادة. ومقالنا عن الامتثال التقني للائحة حماية البيانات يبين كيف يبدو ذلك في الشفرة. والموقف القانوني لا يتغير بين الطريقين.

إتاحة الوصول تنطبق على الأدوات الداخلية أيضا

تبنى الأدوات الداخلية عادة كأن أحدا ممن يستخدمونها لا يمكن أن يكون من ذوي الإعاقة، وهذا خطأ، وهو في بعض المؤسسات مخالف للقانون كذلك.

بموجب المادة 20 من قانون المساواة لسنة 2010 يقع على صاحب العمل واجب اتخاذ ترتيبات تيسيرية معقولة، بما في ذلك اتخاذ الخطوات المعقولة لتفادي ضرر جوهري ناتج عن حكم أو معيار أو ممارسة، وتوفير وسائل مساعدة. ونظام جداول مناوبات لا يمكن تشغيله بلوحة المفاتيح يضع موظفا من ذوي الإعاقة في وضع أسوأ جوهريا، ولا يوجد استثناء لبرمجيات لا يراها عملاؤك أبدا.

وبالنسبة إلى مؤسسات القطاع العام الموقف صريح. فإرشادات GOV.UK بشأن متطلبات إتاحة الوصول تنص على أن مواقع الإنترانت والإكسترانت تشملها لوائح إتاحة الوصول، وأنها يجب أن تستوفي WCAG 2.2 مستوى AA، وأن المواقع الداخلية الأقدم التي نشرت قبل 23 سبتمبر 2019 يجب أن تجعل متاحة عند تحديثها.

والمعايير التي تخفق فيها الأدوات الداخلية أكثر من غيرها هي أكثرها اعتيادا: 2.1.1 لوحة المفاتيح و3.3.2 التسميات أو التعليمات عند المستوى A، و1.4.3 التباين (الحد الأدنى) عند المستوى AA، ومن إضافات WCAG 2.2 المعياران 2.4.11 عدم حجب التركيز (الحد الأدنى) و2.5.8 حجم الهدف (الحد الأدنى)، وكلاهما عند المستوى AA.

في البناء بلا شفرة إتاحة الوصول سقف لا تتحكم فيه

هذه هي نقطة إتاحة الوصول التي تغير قرار البناء مقابل الشراء بدل أن تضيف إليه عملا فحسب.

على منصة بلا شفرة لست أنت من يكتب الترميز. المنصة تولده، فتصير إتاحة الوصول في تطبيقك محكومة بسقف مكتبة مكوناتها. فإذا كان منتقي التاريخ فيها لا يعمل بلوحة المفاتيح، أو كانت نافذتها المنبثقة تحتجز التركيز على نحو سيئ، فلن تستطيع إصلاح ذلك. تستطيع فتح تذكرة دعم والانتظار.

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

وفي البناء المخصص يكون عمل إتاحة الوصول من نصيبك، وهو يكلف أكثر في البداية ويزيل التبعية. اطلب من أي مورد محتمل بيان مطابقة لإتاحة الوصول قبل أن تصمم عملية حول مكوناته، واعتبر غيابه إجابة في حد ذاته.

تقليل مخاطر البناء المخصص بشريحة أولى رفيعة

الطريقة التي تفشل بها المشاريع المخصصة ليست تقنية في الغالب. إنها الالتزام بالميزانية كلها أمام مواصفات كتبت قبل أن يستخدم أحد أي شيء.

البديل شريحة رفيعة: مسار عمل واحد، من طرفه إلى طرفه، في بيئة الإنتاج، يستخدمه شخص حقيقي في عمل حقيقي، خلال ستة إلى ثمانية أسابيع. ليست نموذجا أوليا ولا عرضا توضيحيا، بل أضيق مسار عبر النظام ينتج نتيجة حقيقية، ببيانات حقيقية ومصادقة حقيقية ونشر حقيقي. فإذا كانت العملية هي التسعير، فالشريحة تنشئ عرض سعر وتسعره وترسله.

تفعل تلك الشريحة أربعة أشياء لا تستطيع المواصفات فعلها. تثبت التكاملات، وهناك تسكن المفاجآت. وتقيس سرعة التسليم الحقيقية للفريق بدل تقديرها. وتضع برمجيات عاملة أمام صاحب العملية نفسه، وهو ما يغير المتطلبات على نحو موثوق. وتمنحك مخرجا: أنفقت مبلغا محددا وتملك شيئا يعمل.

ثم ضع نقطة قرار هناك، مكتوبة، قبل الإفراج عن الإنفاق الأكبر. ودليلنا عن كيفية بناء تطبيق ويب يتناول الشكل التقني للشريحة الأولى، وصفحة خدمات تطوير البرمجيات لدينا تشرح كيف نحدد نطاق واحدة منها.

إطار قرار تستطيع تنفيذه في فترة بعد الظهر

لا شيء من هذا يحتاج إلى تعاقد استشاري. يحتاج إلى بضع ساعات وإلى أمانة مع الأرقام.

أولا، اكتب العملية كما تجري فعلا، خطوة خطوة، بما في ذلك الاستثناءات التي يعالجها الناس يدويا. وهذا وحده ينهي النقاش كثيرا، لأنه يكشف أن العمليات ثلاث لا واحدة.

ثانيا، أحص المقاعد اليوم وتوقعها لثلاث سنوات. ثالثا، اختصر القائمة إلى ثلاثة منتجات بالضبط وقيمها مقابل عمليتك المكتوبة لا مقابل قوائم خصائصها، مع تعليم كل موضع يغير فيه تبني المنتج طريقة عملك وما إذا كان ذلك التغيير يكلفك شيئا.

رابعا، سعر فخ المنتصف صراحة: أتعاب التنفيذ والوسيط وجزء الراتب الذي سيديره. خامسا، طبق اختبار اثنين من ثلاثة. سادسا، احسب نقطة التعادل بالأشهر عند عددي المقاعد كليهما. سابعا، إن كان الجواب هو البناء المخصص، فاطلب شريحة رفيعة لا نظاما كاملا.

من ينبغي له أن يغلق هذه الصفحة ويذهب ليشتري شيئا

بعض القراء ينبغي أن يتوقفوا هنا، وقول ذلك بوضوح أنفع من خاتمة متوازنة.

إذا كانت عمليتك شائعة تديرها آلاف الشركات بالطريقة نفسها تقريبا، فاشترِ المنتج. وإذا كان لديك أقل من نحو عشرين مستخدما ولا توجد توقعات تغير ذلك، فاشترِ المنتج أو ابنه على منصة بلا شفرة، لأن حساب المقعد لن ينقلب لصالحك في أي أفق تستطيع التخطيط له. وإذا لم يكن هناك من سيتولى مسؤولية البرنامج بعد تسليمه، فاشترِ المنتج، لأن النظام المخصص بلا مالك يتحول سريعا إلى عبء.

وإذا كنت لا تستطيع وصف عمليتك كتابة، فلا تطلب شيئا بعد. اكتبها أولا. فكثير من المشاريع الفاشلة طلبت بناء على وصف فهمه ثلاثة أشخاص في الغرفة نفسها بثلاث طرق مختلفة، ولا قدر من الهندسة يصلح ذلك.

وإذا تحقق شرط واحد فقط من الثلاثة، فاشترِ المنتج وأعد النظر بعد عام. فالشروط تتغير فعلا، وغالبا لأن عدد الموظفين نما. وإذا كان ما تحتاج إليه في الواقع موقعا موجها للجمهور لا أداة داخلية، فذلك مشروع آخر يغطيه عملنا في تطوير المواقع.

طلب رأي ثان قبل أن تلتزم

الخطأ المكلف في أي من الاتجاهين يرتكب قبل وجود أي شفرة، ولذلك فإن أرخص ما تستطيع شراءه الآن هو تقييم أمين.

تبني Mecanik تطبيقات ويب تشغيلية لشركات بريطانية، وجزء كبير من هذا العمل هو أن نقول للناس إنهم لا يحتاجون إليها. أحضر جدول البيانات وعدد المقاعد والمنتجات الثلاثة التي اخترتها، وسيقوم فريق تطوير البرمجيات المخصصة لدينا إما بتسعير شريحة أولى رفيعة وإما بإخبارك أي منتج تشتري بدلا منها. وإذا كان التطبيق موجها للعملاء لا للاستخدام الداخلي، فابدأ من تطوير المواقع واقرأ مقارنة تطوير الويب المخصص مقابل منصات SaaS، التي تعالج ذلك الوجه من السؤال.

الأسئلة الشائعة

كم تكلفة تطبيق ويب مخصص في المملكة المتحدة؟ التطبيق الداخلي المحدد النطاق الذي يحل محل جدول بيانات واشتراك أو اثنين يكلف بناؤه عادة بين GBP 25,000 وGBP 60,000، وتأخذ منه الشريحة الأولى الرفيعة بين GBP 8,000 وGBP 15,000. وخصص كل عام نسبة إضافية تتراوح بين 15 و20 في المئة من سعر البناء للاستضافة والترقيع وترقية الاعتماديات، لأن أرضية التكلفة تلك لا تصل إلى الصفر أبدا.

هل البناء بلا شفرة بديل حقيقي عن تطوير تطبيق ويب مخصص؟ نعم. فمع السجلات والنماذج وطرق العرض والقواعد البسيطة يكون غالبا هو الإجابة الصحيحة، وهو أسرع بكثير. لكنه يصطدم بجدار عند أعداد الصفوف الكبيرة والصلاحيات المعقدة وسلامة المعاملات وإدارة الإصدارات وآلات الحالات الحقيقية. كما أنه يسعر لكل مقعد: تدرج Retool خطة Business بمبلغ GBP 40 لكل مطور وGBP 12 لكل مستخدم داخلي شهريا، وهو رخيص عند عشرة مقاعد وكبير عند أربعمئة.

عند كم مستخدما يصير البناء أرخص من الشراء؟ اقسم سعر البناء على التوفير الشهري، وهو تكلفة المنتج بكل شيء ناقص الاستضافة زائد جزء من اثني عشر من ميزانية الصيانة السنوية. عند أربعين مستخدما يسترد بناء بمبلغ GBP 45,000 أمام تكلفة منتج شهرية قدرها GBP 2,150 خلال نحو 34 شهرا. وعند أربعمئة مستخدم يسترد في أقل من عام، لأن رسوم المقاعد تتوسع مع عدد الموظفين بينما تكاد تكلفة تشغيل النظام المخصص لا تتحرك.

من المسؤول عن حماية البيانات إذا اشترينا SaaS بدل أن نبني؟ أنت. يعرف ICO المتحكم بأنه الجهة التي تحدد أغراض المعالجة ووسائلها، ومورد SaaS لديك هو في الغالب الأعم المعالج الذي يعمل وفق تعليماتك. وتبقى أنت مسؤولا عن إثبات الامتثال، وعن امتثال معالجيك، وعن عقد بموجب المادة 28(3). فشراء البرمجيات ينقل عمل البنية التحتية لا المسؤولية القانونية.

هل تنطبق قواعد إتاحة الوصول على أدوات داخلية لا يراها أحد من خارج الشركة؟ نعم. تلزم المادة 20 من قانون المساواة لسنة 2010 أصحاب العمل بترتيبات تيسيرية معقولة، والأداة التي لا يمكن تشغيلها بلوحة المفاتيح تضع الموظف من ذوي الإعاقة في وضع أسوأ جوهريا. كما تشمل لوائح إتاحة الوصول شبكات الإنترانت والإكسترانت في القطاع العام، وعليها أن تستوفي WCAG 2.2 مستوى AA. وعلى منصة بلا شفرة يحدد سقف إتاحة الوصول بمكونات المورد.