نظام مخصص ولا برنامج جاهز؟ قارن على طريقة شغلك

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

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

وثق العملية قبل قائمة المميزات

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

فرّق بين ضروري ومفضل وعادة قديمة قابلة للتغيير. لو النظام الجاهز لا يطابق شكل ملف قديم، ده مش عيب تلقائيًا. السؤال هل يمنع إنجاز المهمة أو الرقابة المطلوبة، ولا بس يغير ترتيبًا اعتدتم عليه؟

جرب سيناريو حقيقي على كل اختيار

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

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

احسب ما بعد الإطلاق

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

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

اختبر النقاط الحاسمة قبل الالتزام

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

اكتب معايير قبول لكل مهمة. دليل قصص المستخدم من GOV.UK يساعد وصف من يحتاج الفعل ولماذا، ثم تحديد نتيجة تؤكد إن الحاجة اتغطت. مش كفاية أن المورد يقول «الخاصية موجودة»؛ لازم تتناسب مع السيناريو.

القرار النهائي يحتاج سببًا وحدودًا

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

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