أنظمتك تعمل. لكنها لا تعمل معاً.

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

هل تعرف هذا الموقف؟

الطلب نفسه يُدخَل في نظامين، وأحياناً في ثالث.

المخزون صحيح في مكان وخاطئ في آخر، ولا أحد متأكد أيهما يُصدَّق.

تقرير شهري يستغرق نصف يوم لأن الأرقام موزّعة على أربع منصّات.

يسأل عميل عن طلبه، فتحتاج الإجابة إلى فتح ثلاث شاشات.

اشتريت برنامجين جيدين، وبقيت الفجوة بينهما.

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

لا أحد يشتري فجوة

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

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

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

قد تكون لديك الأنظمة الصحيحة بالفعل

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

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

لكل معلومة نظام واحد يملكها

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

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

واجهة البرمجة أن يسأل نظامٌ نظاماً آخر. والويب هوك أن يُخبر نظامٌ نظاماً آخر بأن شيئاً قد حدث دون أن يُسأل. والمهمة المجدولة تتحقق أو تزامن على فترة تناسب البيانات. ومعظم التكاملات الحقيقية تستخدم الثلاثة: رقم المخزون قد يحتاج الفورية، أما تقارير نهاية الشهر فلا.

حين لا توجد واجهة برمجة

الأنظمة القديمة والمتخصصة كثيراً ما لا تملك واجهة برمجة إطلاقاً. وهذا لا يضعها خارج المتناول.

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

كيف نتعامل معها

1

الفهم

رسم خريطة للقائم: الأنظمة، وما تملكه كل منها من بيانات، والخطوات اليدوية التي بُنيت حولها.

2

القرار

الاتفاق على ما يجب ربطه، وما يبقى كما هو، وما لا يستحق الأتمتة أصلاً.

3

البناء

تنفيذ الربط — واجهة برمجة أو ويب هوك أو مهمة مجدولة أو موصّل مخصص، بحسب ما تدعمه الأنظمة فعلاً.

4

الانتقال

تشغيل القديم والجديد جنباً إلى جنب، ومطابقة النتائج، ثم التحول حين تتفق الأرقام.

5

البقاء

المتابعة، والإصلاح حين يغيّر مزوّد واجهته، ومواصلة التحسين. نبنيه، ونشغّله، ونبقى.

حللنا هذا من قبل

Urban Industry — أزياء الشارع، إيستبورن

تبيع Urban Industry أكثر من 2,500 منتج لأكثر من مئة علامة تجارية، عبر متجرها الخاص وعبر المنصّات وفي المعرض. لم تكن المشكلة في منصّة بعينها، بل في أن المخزون والطلبات والشحن كانت تعيش في أماكن مختلفة، والشركة تنمو أسرع مما يمكن مطابقته يدوياً.

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

بنينا منصّة بيع للأفراد تمنح الفريق رؤية واحدة للمخزون والطلبات والشحن عبر كل قنوات البيع، ثم ربطناها بالخارج: PayPal وCheckout by Amazon للدفع، وواجهة متجر مخصصة كبائع مميّز على Amazon UK، وMetaPack ليصل الطلب إلى العملاء حول العالم بالطريقة التي تناسبهم.

اقرأ القصة كاملة ←

متعدد القنوات
المتجر والمنصّات والمعرض
مدفوع بالبحث
نمو عضوي وحضور للعلامة
حائز على جوائز
متجر مستقل معترف به

ما يتضمنه هذا عادةً

واجهات البرمجة والتكامل

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

برمجيات مخصصة

حين تحتاج المساحة بين نظامين إلى شيء مصمَّم ليقف فيها.

حلول قواعد البيانات

تصميم ورعاية البيانات التي يعتمد عليها كل ما عداها.

التجارة الإلكترونية

متاجر مبنية للبيع، وللتحدث مع الأنظمة خلفها.

أسئلة تُطرح علينا

هل يمكنكم التكامل مع برنامج طوّره غيركم؟

غالباً نعم، وهذا هو الحال الأكثر شيوعاً. المهم ما يعرضه النظام وما يُتاح لنا من صلاحيات، لا من كتبه.

وماذا لو لم يكن لأحد أنظمتنا واجهة برمجة؟

ننظر عندئذٍ في واجهة مع قاعدة البيانات، أو تبادل ملفات مؤمَّن، أو وسيط برمجي، أو موصّل مخصص. هذا جهد أكبر من واجهة موثّقة، وسنخبرك أيّها قبل أن نبدأ.

هل يلزم استبدال شيء؟

غالباً لا. إذا كانت أنظمتك تؤدي عملها، فالجواب هو الوصل بينها. نفضّل أن نقول ذلك على أن نبيعك إعادة بناء.

كم يستغرق التكامل؟

يعتمد أساساً على أسوأ الأنظمة توثيقاً. بين منصّتين حديثتين قد يستغرق أياماً؛ ومع قاعدة قديمة غير موثّقة يمضي معظم الوقت في فهمها لا في كتابة الشيفرة.

هل تدعمونه بعد ذلك؟

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

أخبرنا أي الأنظمة يجب أن تتحدث معاً.

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

نبني أنظمة الأعمال ونُشغّلها منذ عام 2000. الفريق الذي يبنيها هو الذي يبقى لتشغيلها.

ابدأ المحادثة