العرض بيقول 'تطوير CRM' — ده برمجة مخصوصة ولا تركيب أداة جاهزة؟

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

في وكالات بتحب تغيّر ثيم نظام جاهز وتربط فيه فورمين وتسمي ده 'تطوير' وتطلع فاتورة منفوخة. لو بتدفع 14,500 £، الفاتورة دي لازم يكون فيها على الأقل دمج API حقيقي شغال مع برنامج المحاسبة ونظام تتبع اللوجستيات بتاعك. أما لو هيعملوا بس إعدادات سحب وإفلات، فالرقم ده كتير أوي.

السنة اللي فاتت جمعنا عروض لعملية توزيع مشابهة. للتركيبات الجاهزة القياسية طلبوا بين 4,000 £ و6,000 £. ولما دخل في الموضوع برنامج مزامنة مخصوص مع قاعدة بيانات المخزن ووحدة عروض مخصوصة، الوكالة اللي اتفقنا معاها طلعت فاتورة 12,000 £. رقم الـ 14,500 £ بتاعك، لو فيه كود دمج مخصوص، في الحد المعقول للسوق البريطاني.

قبل ما تدخل الاجتماع، ابعت للوكالة إيميل من سطر واحد: 'بند تطوير CRM في العرض معناه كتابة برنامج مسجّل من الصفر ولا تطوير API/وحدات لنظام طرف تالت؟' على حسب الرد هتحدد استراتيجيتك في الاجتماع وما تضيعش وقت.

الـ CRM ده محتاج يتكلم مع أي أنظمة في العملية؟ لو هيتكلم أوتوماتيك مع الـ ERP أو السنترال أو البنية بتاعة التجارة الإلكترونية الموجودة عندك، فمعظم التكلفة رايحة على كتابة الجسور دي. ما بعتوش مع العرض مخطط معماري أو قائمة متطلبات وظيفية؟

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

سنة 2021 اتفقنا مع فريق قال 'بنكتب لكم CRM مخصوص'. خد 8 شهور، والميزانية بقت الضعف، وفي الآخر حتى زرار تصدير إكسل بسيط طلعنا نضيفه بصعوبة في 3 أسابيع. بعدها رمينا كل حاجة وانتقلنا لبنية جاهزة وكتبنا بس وصلات الـ API اللازمة. كانت أغلى درس في حياتنا.

لما التطوير يكون فوق نظام جاهز، لو افترقنا عن الوكالة دي يوم من الأيام، مبرمج تاني يقدر يورث الكود ده ويكمّل، ولا كل حاجة هترجع من الصفر؟

دعني أشارك تجربتي. إذا لم تُكتب معايير القبول، فإن وقت انتهاء العمل يبقى مفتوحاً للنقاش.

بالتوفيق.

بالضبط هكذا. إذا لم تقم بصياغة هذا كتابيًا من البداية، فستنشأ خلافات لاحقًا.

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

سأكون ممتنًا لو شاركت النتيجة.

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

دعني أتركها كملاحظة، قد تكون مفيدة.

الطريق الذي يبدو رخيصاً غالباً ما يكلف غالياً لاحقاً. أرخص عرض سعر هو غالباً الأقل تفكيراً.

لو كنت مكانك، لسلك هذا المسار.

قضيت وقتًا طويلاً في هذا المجال. بصراحة وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه.

أرخص عرض سعر هو غالباً الأقل تفكيراً. على كل حال صححوا لي إن أخطأت.

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

لو كنت مكانك، لسلك هذا المسار.

أنا أيضًا أوافق على هذا الرأي. وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه.

تم الحفظ. الكود بدون وثائق تثبيت لا يُعتبر ملكك حتى لو كان بين يديك.

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

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

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