الأسئلة الشائعة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XSIS. فعقدك معنا، وقائد التنفيذ لدينا مسؤول عن عمل الفريق بأكمله، أيا كانت الجهة التي توظف كل مهندس. ولهذا يراجع مهندسونا التغييرات التي يقدمها المهندسون الخارجيون قبل دمجها، ولهذا تطبق مجموعة واحدة من المعايير على الجميع.

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

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

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

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

نعمل مع نماذج تجارية مثل نماذج OpenAI GPT وAnthropic Claude وGoogle Gemini، ومع نماذج مفتوحة مثل Meta Llama وMistral، ومع تعلم الآلة التقليدي حين يكون أنسب. ونختار لكل مهمة بحسب الجودة والتكلفة وزمن الاستجابة والمكان الذي يجوز تشغيل النموذج فيه، ونصمم بحيث يمكن تغيير النموذج لاحقا. وذكر اسم مورد لا يعني وجود شراكة معه.

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

للإجابة من مستنداتك، يكون الاسترجاع عادة البداية الأفضل: فهو يبقي الإجابات محدثة، ويعرض المصادر، ويحترم الصلاحيات. أما الضبط بالتدريب الإضافي (fine-tuning) فيفيد حين تحتاج إلى صيغة أو أسلوب ثابت، أو مفردات متخصصة، أو نموذج أصغر منخفض تكلفة التشغيل. وتجمع أنظمة كثيرة بين الأسلوبين. نختبر الخيارات على مجموعة التقييم لديك، ونوصي بأبسطها الذي يحقق المستوى المطلوب.

نختار لكل مهمة بناء على جودة الإجابات في مجموعة التقييم لديك، وتكلفة الطلب الواحد، والسرعة، ودعم اللغات، والمكان الذي يسمح بتشغيل النموذج فيه. ومن الخيارات نماذج OpenAI GPT وAnthropic Claude وGoogle Gemini وMeta Llama وMistral، عبر خدمات مثل Azure OpenAI أو Amazon Bedrock أو Vertex AI. ويعمل النموذج خلف واجهة واحدة، فيمكن استبداله لاحقا.

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

يعتمد ذلك على سحابتك وأحجام بياناتك ومهارات فريقك وميزانيتك أكثر مما يعتمد على منتج بعينه. تعمل Snowflake وDatabricks وBigQuery وAmazon Redshift جيدا لدى معظم الشركات، ويكفي PostgreSQL لكثير منها. نقارن الخيارات بمتطلباتك وعقودك القائمة، ونصمم بحيث تبقى التحويلات المكتوبة بلغة SQL باستخدام dbt قابلة للنقل.

نعم. نستخدم طرق الاستخراج التي يدعمها نظام ERP، مثل واجهات API أو خدمات التصدير أو التقاط التغييرات من نسخة متماثلة، بدلا من الاستعلامات الثقيلة على قاعدة البيانات الحية. ونجدول التحميلات خارج ساعات الذروة عند الحاجة. ومع SAP وOracle وMicrosoft Dynamics 365 وNetSuite وOdoo نتبع النهج الذي توصي به كل جهة مطورة.

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

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

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

نرحل إلى SAP S/4HANA وOracle NetSuite وMicrosoft Dynamics 365 وOdoo وSage، وإلى الأنظمة المخصصة وأنظمة سير العمل، عبر واجهات API أو خدمات الاستيراد أو منصات التكامل الخاصة بها. ويتبع الترحيل قواعد الاعتماد نفسها التي يطبقها فريقك اليوم. وذكر منتج هنا لا يعني وجود شراكة مع الجهة المطورة له.

ننطلق مما يستطيع فريقك تشغيله وتوظيف الكفاءات له، ومما تستخدمه أنظمتك الأخرى، ومما يجب أن تؤديه البرمجيات. ويعني ذلك في معظم برمجيات الأعمال لغة شائعة مثل TypeScript أو Java أو C# أو Python، وقاعدة بيانات علائقية مثل PostgreSQL أو SQL Server، والسحابة التي تستخدمها حاليا. نتجنب الأدوات المتخصصة النادرة ما لم تحل مشكلة حقيقية، ونوثق كل خيار وأسبابه.

نستخدم React مع Next.js في معظم التطبيقات الجديدة، لأنه يدعم العرض على الخادم، ويتمتع بأدوات قوية، ويعرفه عدد كبير من المهندسين. ونعمل أيضا مع Angular وVue، ونواصل العمل بإطار العمل الذي تستخدمه حاليا عندما يكون ذلك الخيار المنطقي. يعتمد القرار على مهارات فريقك، وما يجب أن يؤديه التطبيق، وما ستتولى صيانته لاحقا.

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

تمنح التطبيقات الأصلية المكتوبة بلغتي Swift وKotlin أوسع وصول إلى قدرات الجهاز وأقرب توافق مع كل منصة. أما التطبيقات متعددة المنصات المبنية بإطاري React Native أو Flutter فتشترك في معظم شيفرتها بين iOS وAndroid، ما يخفض تكلفة بنائها وتغييرها. نوصي بالتطبيق الأصلي عندما يعتمد التطبيق اعتمادا كبيرا على الجهاز، كأجهزة الدفع أو الوسائط المعقدة، وبالتطبيق متعدد المنصات لمعظم تطبيقات الأعمال والمستهلكين.

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

عادة المزود الذي تستخدمه بالفعل، ما لم يكن هناك سبب واضح للتغيير. فكل من Amazon Web Services وMicrosoft Azure وGoogle Cloud يشغل أحمال عمل المؤسسات جيدا. والعوامل الحاسمة هي عقودك ومهاراتك القائمة، والخدمات المدارة التي تحتاج إليها، وقواعد إقامة البيانات، وطريقة اتصال أنظمتك الأخرى. نعمل على المزودين الثلاثة، ونحصر الشيفرة الخاصة بمزود بعينه في المواضع التي تستحق ذلك.

نستخدم الأدوات التي تلائم تقنياتك وفريقك: Playwright أو Cypress للاختبارات الشاملة على الويب، وAppium للأجهزة المحمولة، وJest أو JUnit أو pytest لاختبارات الوحدات، وPostman لفحوص API، وk6 أو JMeter للأداء، وOWASP ZAP للفحص الأمني. ونحفظ الاختبارات في مستودعك وبلغة البرمجة التي يستخدمها مهندسوك قدر الإمكان، ليتمكنوا من صيانتها.

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

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

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

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

نعمل بالتقنيات التي بنيت عليها كثير من أنظمة الأعمال، ومنها الإصدارات القديمة من Java و.NET، وقواعد البيانات العلائقية مثل Oracle Database وSQL Server، وخدمات SOAP، والواجهات القائمة على الملفات. وفي المنصات الأندر، نقيم الشيفرة أولا ونخبرك بوضوح هل نملك المهارات اللازمة، أم ينبغي أن ينضم إلى الفريق متخصص.

نعمل مع SAP S/4HANA وSAP Business One، وOracle NetSuite، وOracle Fusion Cloud ERP، وMicrosoft Dynamics 365 Finance وSupply Chain Management، وDynamics 365 Business Central، وOdoo، وSage Intacct وSage X3، إلى جانب الأنظمة المخصصة والأنظمة القديمة. ونستخدم مع كل منها الواجهات التي يدعمها المورد، حتى لا تعطل الترقيات التكامل. وذكر أي منتج لا يعني وجود شراكة مع الشركة المالكة له.

ليس دائما. فبضعة مسارات ثابتة بين نظامين يمكن أن تكون استدعاءات API مباشرة. أما عندما تتبادل عدة أنظمة البيانات، أو تحتاج إلى ربط الحقول وقوائم الانتظار والمراقبة في مكان واحد، فإن البرمجيات الوسيطة مثل MuleSoft أو Boomi أو Azure Logic Apps تسترد تكلفتها عادة. وإذا كنت تملك إحداها، نبني عليها. ونعرض عليك المفاضلات، بما فيها تكاليف التراخيص، قبل أن تقرر.

نعمل برسائل ISO 20022 التي تستخدمها البنوك في مدفوعات الشركات وتقاريرها: pain.001 للمدفوعات، وpain.002 للحالة، وcamt.052 وcamt.053 وcamt.054 لتقارير الحسابات. ونتعامل أيضا مع كشوف SWIFT MT940 وMT942 التي لا تزال بنوك كثيرة ترسلها. وللنقل نستخدم host-to-host عبر SFTP، وEBICS حيث توفره البنوك، وواجهات API المصرفية. ولكل بنك نسخته الخاصة من كل صيغة، لذا نبني وفق دليل التطبيق الصادر عن البنك، لا وفق المعيار وحده.

نربط البنوك بأنظمة SAP S/4HANA وOracle NetSuite وOracle Fusion Cloud ERP وMicrosoft Dynamics 365 وOdoo وSage، وبأنظمة الخزينة والأنظمة المخصصة. ولدى بعض أنظمة ERP وحدات خاصة للاتصال المصرفي، وفي هذه الحالة نهيئها ونوسعها بدلا من البناء حولها. وذكر أي منتج هنا لا يعني وجود شراكة مع الشركة المالكة له.

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

ندمج أجهزة EMV بالشريحة والدفع اللاتلامسي عبر البروتوكول الذي يوفره مزودها، وهو عادة واجهة API محلية أو سحابية بين نظام نقاط البيع والجهاز. والجهاز وتطبيق الدفع عليه معتمدان من المزود، لذا نتكامل معهما دون تغييرهما. ونؤكد معك ومع المزود الطرازات والبروتوكولات بدقة في البداية.

يعتمد ذلك على عدد الاتصالات لديك ومن سيتولى تشغيلها. فمنصة التكامل مثل MuleSoft أو Boomi أو Azure Logic Apps توفر لك موصلات جاهزة وربطا للحقول ومراقبة في مكان واحد، مقابل تكلفة ترخيص. أما الخدمات المخصصة فتمنحك تحكما كاملا دون ترخيص، لكنك تتولى صيانة شيفرة برمجية أكثر. ونقارن بين الخيارين في حالتك، ونبني على منصة تملكها بالفعل.

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

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

نعم. نبني خدمات تنشئ رسائل ISO 20022 وتتحقق منها وتقرؤها، سواء لمدفوعات الشركات وتقاريرها، مثل pain.001 وcamt.053، أو للرسائل بين البنوك التي تستخدمها أنظمة المدفوعات الفورية والمدفوعات عالية القيمة. ولكل نظام دفع ولكل بنك قواعده الخاصة، لذلك نعمل وفق أدلة التنفيذ الصادرة عنهم ونختبر في بيئات الاختبار لديهم.

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

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

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

نعم. نبني مسارات EDI بصيغتي EDIFACT وANSI X12 ونصونها، عبر AS2 أو SFTP أو شبكة القيمة المضافة، للطلبات وإشعارات الإرسال والفواتير ورسائل الحالة. كما نحول رسائل EDI إلى واجهات API وأحداث، فلا تحتاج الأنظمة الأحدث إلى قراءة EDI بنفسها، ونختبر كل مسار مع الشريك التجاري قبل إطلاقه.

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

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

نعم. نبني واجهات ترسل رسائل HL7 v2 وتستقبلها، مثل رسائل الدخول والطلبات والنتائج، وخدمات تتيح موارد FHIR أو تستهلكها. ونحول الرموز المحلية إلى المصطلحات التي يتوقعها شركاؤك، ونختبر مع أنظمة الاختبار لديهم قبل إطلاق أي شيء.

نعم في الغالب، عبر الواجهات التي يوفرها مزود النظام: تدفقات HL7 v2، أو واجهات FHIR API، أو محرك تكامل. ويشترط بعض المزودين التسجيل أو الموافقة قبل إطلاق أي تكامل. لذلك نراجع وثائق المزود مبكرا، لأنها تحدد النطاق والخطة.

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

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

لا، إذا بنيت بالطريقة الصحيحة. نستخدم نقاط التوسعة المدعومة في نظام ERP، مثل واجهات API والأحداث وأطر التوسعة، ونبقي الكود المخصص منفصلا عن المنتج القياسي. وكل امتداد موثق ومختبر، فيمكن التحقق منه مقابل أي إصدار جديد قبل التحديث.

نعمل مع SAP S/4HANA وSAP Business One، وتطبيقات Microsoft Dynamics 365 (Finance وSupply Chain Management وBusiness Central)، وOracle NetSuite، وOracle Fusion Cloud ERP، وOdoo، وSage Intacct وSage X3. وذكر أي منتج لا يعني وجود شراكة مع الجهة المزودة له. أخبرنا بالإصدار والوحدات لديك، لأنها تحدد خيارات التكامل.

نعم. نصمم التكاملات لتتعامل مع عدة كيانات قانونية وعملات وبنوك وقواعد ضريبية من منصة واحدة، مع تعريف خصائص كل كيان في الإعدادات لا في الكود. وهكذا تعني إضافة كيان جديد إضافة إعدادات واختبارات، لا بناء تكامل جديد.

القرار في الغالب للبنك. فقناة host-to-host بنظام SFTP هي الأوسع انتشارا لملفات مدفوعات الشركات، وEBICS شائع لدى البنوك في ألمانيا وفرنسا والدول المجاورة، أما واجهات API البنكية فتناسب الأرصدة الفورية والمدفوعات اللحظية حيث يتيحها البنك. وتستخدم شركات كثيرة أكثر من قناة، وتخفي طبقة التكامل هذا الاختلاف عن نظام ERP.

إذا أتاح البنك الصيغتين، فإن camt.053 تحمل بيانات سداد أغنى ومنظمة، مما يجعل المطابقة الآلية أكثر موثوقية. أما MT940 فلا تزال مستخدمة على نطاق واسع وتؤدي الغرض في حالات كثيرة. ويمكننا استلام الصيغتين وتحويلهما إلى النموذج الداخلي نفسه، ثم نقل كل بنك من MT940 إلى camt.053 في الوقت الذي يناسبك ويناسب البنك.

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

يعمل التصميم مع أي نظام نقاط بيع يستطيع تصدير المعاملات عبر واجهة API أو أحداث أو ملفات، ومع أنظمة ERP مثل SAP S/4HANA وOracle NetSuite وMicrosoft Dynamics 365 Business Central وOdoo. ونتأكد من واجهات نظامي نقاط البيع وERP لديك في البداية. وذكر أي منتج لا يعني وجود شراكة مع الشركة المالكة له.

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

لا. يحدد ISO 8583 هيكلا عاما، وينشر كل بنك محصل أو شبكة مواصفاته الخاصة للحقول وأنواع الرسائل والرموز. ولهذا نبني وفق مواصفات البنك المحصل ونجري اختبارات الاعتماد الخاصة به. وواجهة API لبوابة تقف أمام البنك المحصل تخفي هذه الفروق، وهو خيار أبسط غالبا لشركات التجزئة.

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

تتوقف التغطية على أنظمة كل منطقة وعلى واجهات API لدى البنوك. ففي الاتحاد الأوروبي والمملكة المتحدة تغطية واسعة بموجب PSD2 وUK Open Banking Standard، وتتفاوت التغطية في غيرهما، ويسد مجمعو البيانات المصرفية بعض الفجوات. ونتحقق من التغطية للبنوك التي يستخدمها عملاؤك قبل أن تعتمد التصميم.

ليس في معظم أعمال الخزينة لدى الشركات. فقنوات host-to-host تتولى ملفات المدفوعات المجمعة وكشوف الحساب الكاملة لحساباتك أنت. أما المصرفية المفتوحة فتناسب المنتجات الموجهة للعملاء، والأرصدة الفورية، والمدفوعات الفردية. وتستخدم شركات كثيرة الاثنين معا: host-to-host لدورات الدفع الخاصة بها، والمصرفية المفتوحة لعملائها.

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

عندما يرتبط عدة شركاء بنظام ERP واحد، فإن منصة مثل MuleSoft أو Boomi أو Azure Logic Apps، أو مجموعة من الخدمات المخصصة المبنية على قائمة انتظار للرسائل، تجمع التحويل وإعادة المحاولة والمراقبة في مكان واحد. أما مع شريك أو شريكين فقد يكفي الربط المباشر. ونعرض لك المفاضلات في حالتك، بما فيها تكاليف التراخيص.

XSIS هي شركة التقنية في KONG GROUP. نصمم البرمجيات ونبنيها ونربطها ونشغلها للمؤسسات: الذكاء الاصطناعي والبيانات، والبرمجيات المخصصة، والويب والأجهزة المحمولة، والسحابة، والتكاملات التي تربط أنظمة ERP بالبنوك ونقاط البيع والجهات الخارجية. التقنية المالية قطاعنا الرئيسي. ننفذ العمل من خلال مهندسينا الداخليين وفرق خارجية اعتمدناها بعد تقييمها، وفق مجموعة واحدة من المعايير.

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

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

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

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

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

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

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