أنظمة المؤسسات · منتجنا الخاص

نظام SaaS بُني بالطريقة الأصعب

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

  • قاعدة بيانات لكل مستأجر
  • توقيع زاتكا داخل دفتر الأستاذ
  • العربية أولاً وباللغتين

نبذة عن المشروع

العميل
فالور إكس (منتج داخلي)
القطاع
برمجيات كخدمة · محاسبة وERP
التسليم
2026 — قيد التشغيل
الخدمات
برمجيات مخصصة، حلول سحابية، ويب

الوضع السابق

طريقتان يموت بهما أي منتج ERP

بدأنا هذا المشروع لأن كلا النمطين كان ظاهراً في أنظمة طُلب منا إنقاذها، والبنية التي اخترناها ردّ مباشر عليهما.

  1. 01

    ابنِ كل شيء ولا تطلق شيئاً

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

  2. 02

    أطلق بسرعة وأعد البناء لاحقاً

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

  3. 03

    جداول مشتركة ومخاطر مشتركة

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

  4. 04

    الالتزام كإضافة لاحقة

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

ما بنيناه

البنية خلف المنتج

قرارات اتُّخذت قبل تصميم أول شاشة، لأن أياً منها لا يمكن إضافته لاحقاً بتكلفة معقولة.

  • قاعدة بيانات لكل مستأجر

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

  • طبقة تحكم مشتركة

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

  • نموذج ERP كامل من اليوم الأول

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

  • محرك ترحيل في القلب

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

  • زاتكا داخل المسار

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

  • واجهة بالعربية أولاً

    ثنائية اللغة من أول مكوّن، بتخطيط من اليمين لليسار مصمم لا معكوس، لأن المحاسب ليس من يجب أن يتكيّف.

ما الذي تغيّر

منصة تستوعب الوحدة التالية دون إعادة بناء

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

  • العميل الجديد تُهيَّأ له قاعدة بياناته آلياً
  • إضافة وحدة تعني جداول جديدة لا إعادة كتابة المخطط
  • يمكن تصدير مستأجر أو نقله إلى استضافة خاصة عند الطلب
  • مخرجات الالتزام تُنتج من دفتر الأستاذ لا تُطابق معه
  • 41

    وحدة على نموذج بيانات واحد

  • 195

    ترحيلاً يُطبَّق لكل شركة

  • 66

    مجموعة واجهات خلف بوابة واحدة

بُني باستخدام

تقليدية عن قصد حيث يهم الأمر: نواة علائقية وترحيلات صريحة ولا إطار يصعب التوظيف عليه.

الواجهة الأمامية
  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • React Query
  • next-intl
الخلفية
  • Node.js
  • Express
  • Sequelize
  • ترحيلات Umzug
  • Zod
البيانات والأمن
  • PostgreSQL
  • Argon2
  • JWT
  • Helmet
  • تحديد المعدل
الالتزام والمستندات
  • توقيع XML
  • node-forge
  • رموز QR
  • Puppeteer PDF
  • ExcelJS

تفكر في بناء منتج لا مجرد مشروع؟

تعدد المستأجرين والتهيئة ونموذج بيانات يصمد أمام الوحدة الثانية قرارات يُفضَّل اتخاذها قبل الأولى، ونحن اتخذناها.