إذا بدأنا بأدوات بلا برمجة، هل سنضطر لإعادة البناء لاحقًا؟

الشاشة نفسها، طريقتان لبنائها

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

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

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

ثلاث نقاط تتعثر فيها الأدوات بلا برمجة فعلًا

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

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

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

خفض كلفة الانتقال قبل الحاجة إليه

الثلاثة كلها مسائل مستقبلية، ولهذا يصعب الحكم عليها اليوم. لذا أيًا كان الاتجاه الذي تختاره، هناك أمران يستحقان التأكد منهما الآن.

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

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

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

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