تسليم تطبيق ويب/فلاتر مخصّص

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

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

التحدي: نظام واحد لا يفي بالغرض

كان لدى العميل نظام ويب قديم عجز عن متابعة نموّ عملياته، ولم تكن هناك قناة جوالة تصل إلى فريقه الميداني. أمام المجموعة خياران كلاهما مُرْهِق: إمّا مورّد لتطبيق الويب وآخر لتطبيق الجوال، فتنشأ فجوة بين النظامين وتتضاعف تكلفة التنسيق؛ وإمّا محاولة إصلاح النظام القديم بما لا تحتمله تكلفة صيانته المتزايدة.

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

الحل: فريق واحد يسلّم الواجهتين معاً

سلّمت الأنظمة المتجددة المشروع عبر خدمة تطبيقات ويب مخصّصة تغطي الواجهتين معاً. بُنيت واجهة الويب على إطار عمل مؤسسي مستقر، وجاء تطبيق الجوال بتقنية فلاتر (Flutter)، تقنية من Google تبني تطبيقاً واحداً يعمل على iOS و Android معاً، فتختصر إعادة البناء لكل منصة على حدة.

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

النتيجة: تسليم ضمن الجدول المحدد

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

والأهم أن العميل تسلّم نظاماً يدعمه فريق واحد لا فريقان متباعدان. حين يطرأ تعديل أو يظهر طلب جديد، يكون الباب واحداً، والتغيير ينعكس على الواجهتين معاً دون تنسيق متعدد الأطراف.

ما الذي يحدد نجاح التسليم المخصّص

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

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

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

خلاصة

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

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